Subject: Re: Re: Comments to draft-ietf-pwe3-arch-00

From: Danny McPherson <[email-masked]>
Date: Fri, 01 Nov 2002 08:19:34 -0700

> Creating  a  multi-point system  out  of p2p  wires  is  definitely a  PPVPN
> function  rather  than a  PWE3  function.  But  that  doesn't  rule out  the
> possibility of PWE3 defining a p2mp wire of some sort.  Whether such a thing
> is actually needed is an open question.

I tend to agree with Eric here and would like to see some 
discussion of drivers for the work.

> I think this should just be punted for now, left "for further study". 

My first inclination is to agree.  However, begin that there is 
apparent interest and it's technically chartered (at least in the
case of Ethernet), we should at least give it some opportunity for
consideration.

I'd be interested in what others think...

-danny

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 02 Nov 2002 01:59:22 +0000

Some comments on some of Sasha's comments on the arch doc.
The rest of his comments are reflected in ammendments to the
draft.

Stewart

>    The generic cell payload service will normally need sequence number
>    support, and may also need real-time support.  The generic cell
>    payload service would not normally require fragmentation.
> [Sasha] It may be worth noting that cell payload usually
> [Sasha] do not requires length services from either the 
> [Sasha] PSN or the PSN Convergence sub-layer. 

You are right for any cell I can think of, but I would hate to
make it look mandatory to not have a length and then discover
a payload that needed one.

>    For troubleshooting purposes, it is sometimes desirable to know the
>    exact functional path of a PW between PEs, thus a traceroute function
>    capable of reporting the path taken by data packets over the PW
>    should be provided. The opaque nature of the PW means that this
>    traceroute information is only available within the provider network
>    e.g. at the PEs.
> [Sasha] We have just had a long discusion on tunnel and PW tracing during
> [Sasha] the WG Last Call on the PWE3 requirements document. I suggest to
> [Sasha] wait and see which course of action is taken by the authors of
> [Sasha] requirements document. In any case the para above sounds like
> [Sasha]a requirement to me as it does not introduce any architecture.

Yes, it needs a re-word, but I think we need to see what is said
about this at the meeting.

> 10.2  Validation of PW Encapsulation
> 
>    Protection mechanisms must address the spoofing of tunneled PW data.
>    The validation of traffic addressed to the PW Demultiplexer end-point
>    is paramount in ensuring integrity of PW encapsulation.  Security
>    protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer
>    Layer in order to maintain the integrity of the PW by authenticating
>    data between the PW Demultiplexer End-points.  IPSec may provide
>    authentication, integrity, non-repudiation, and confidentiality of
>    data transferred between two PEs.  It cannot provide the equivalent
>    services to the native service.
> [Sasha] IMHO, the PMI implies that authentication,integrity etc. services
> [Sasha] to the native service are NOT provided by any element in the PWE3
> [Sasha] domain. The only place for these would be in the NSP.
> 

I think that the original text is OK, so seek a wider view.

---

From: Sasha Vainshtein <[email-masked]>
Date: Sat, 2 Nov 2002 14:15:02 +0200

Stewart, Cheng-Yin at all,
IMHO, manual set-up of PWs does not provide an
answer to the P2MP PW problem.
Please consider the case when one more PE, that has been
previously running some P2P PWs and allocated some demultiplexor
values accordingly, decides to join (from whatever reason)
the IP multicast group used by a P2MP PW. From what little
I know about IP multicast, it is a perfectly valid operation
(especially if you do not limit the use IP multicast group 
to carrying a single P2MP PW). 
Now, if, by chance, the new multicast group member happens 
to use the demultiplexor value of the P2MP PW for one
of the P2P PWs it has been running before, the result would be
a mess. If it doesn't, it would start receiving packets
it does not know how to deal with... also a mess!
And, AFAIK, the ingress PE would remain completely unaware
of the new group member and the need to deal with it!
I cannot say that I hjaveinvested much thought into the
P2MP issue, but, so far, I have not found a way out -
unless one says that a single multicast IP address must be
allocated per a P2MP PW. This is not the way "normal" tunnels
- be they IP or MPLS - are treated and, to me, explicitly
contradicts the prinicple of core routers being unaware of
individual PWs as stated in the Charter.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Friday, November 01, 2002 9:56 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00
> 
> 
> Cheng-Yin
> 
> To clarify: the sort of thing that you have in mind is to
> explicitly cover the multicasting of Ethernet over the WAN
> using something like IP or MPLS multicast?
> 
> Although this is not explicitly called out, you can do this
> with the specs as they exist today, by for example, using
> L2TPv3 in manual configuration mode and using an IP multicast
> address as the IP DA.
> 
> Is there anyone who has an application for this mode?
> 
> The only use that I can see for this is to avoid replication
> of broadcast packets when building a L2VPN, but I am not sure
> the saving in packet replication justifies the complexity of
> effectively running two parallel PW networks (ie the broadcast
> network plus the point to point mesh). However that is a call
> that the PPVPN WG need to make.
> 
> Regards
> 
> Stewart
> 
> Cheng-Yin Lee wrote:
> > Danny,
> > I was referring to Ethernet specifically in my previous email
> > 
> http://www.ietf.org/mail-archive/working-groups/pwe3/current/m
> sg03096.html
> > The Ethernet 'wire' inherently allows broadcasting. In my 
> view, a bridge emulates
> > an Ethernet 'wire'. OTOH, whether bridging is done at 
> PE/L2PE/CE, I believe, is
> > out of the scope of PWE3.
> > 
> > For services where multipoint transmission is not a 
> property of the "wire", I
> > agree multipoint discussion is out of scope.
> > 
> > thanks
> > cheng-yin
> > 
> > Danny McPherson wrote:
> > 
> >
> >>_______________________________________________
> >>pwe3 mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> > 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Sat, 2 Nov 2002 14:36:17 +0200

Stewart, Prayson and all,
Please see some responses inline.

> Sent: Saturday, November 02, 2002 3:59 AM
> To: Sasha Vainshtein
> Cc: Prayson Pate (E-mail); PWE3 WG (E-mail)
> Subject: Re: Comments to draft-ietf-pwe3-arch-00
> 
> 
> 
OK.
> about this at the meeting.
OK
> I think that the original text is OK, so seek a wider view.
OK.

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 2 Nov 2002 08:52:23 -0500

Sasha,
I am NOT suggesting using IP multicast (I don't believe Stewart is
either).

regards
cheng-yin

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 4 Nov 2002 15:58:39 -0500

Eric,

Eric Rosen wrote:

> In that  draft, the emulated LAN  is created by  interconnecting MAC address
> forwarders with point-to-point pseudowires.  
the function provided _is_ Ethernet Pseudo-Wire

> This pretty clearly falls under
> the scope  of PPVPN,  
An emulated LAN is not necessarily a PPVPL.

Let me ask you this question, how do you define an Ethernet Pseudo-wire?

thanks
cheng-yin
p.s 
> where there  are a number  of much  more comprehensive
> drafts on the topic.
The requirements are broader in PPVPN and it is possible that some of
the problems have not been partitioned or perhaps the problem chosen to
be solved (e.g. bridging customer traffic in the network) is a lot more
challenging and difficult to scale,  but we are digressing.

---

From: Sasha Vainshtein <[email-masked]>
Date: Sat, 9 Nov 2002 15:13:10 +0200

Cheng-Yin, Stewart and all,
I believe that Stewart has posed a correct question:
what is an Ethernet wire?

And I also believe that the PWE3 task is to emulate
wires, not hubs, switches or bridges (regardless of
the need for such emulation which I do not deny in the least).

Some Ethernet wires (e.g., a coax with multiple T connectors)
are indeed multicast. Some others (e.g., a twisted pair)
are not, leaving this task to hubs,switches etc.

I cannot say that I have invested much thought into 
constructive attempts to emulate multicast Ethernet wires.
It seems clear to me that "naive" extensions of the existing
PWE3 architecture do not solve this problem. I am also not
so sure this problem realy requires a solution - because
partitioning it between P2P PWs and bridge-like Forwarder blocks
seems to cover most needs at reasonable price (replication of
broadcast/multicast frames at the ingress PE and not somewhere
in the core network).

> From: Cheng-Yin Lee [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 11:28 PM
> To: [email-masked]
> Stewart,
> Thanks for taking my comments into consideration. Some 
> comments inline.
> 
> Stewart Bryant wrote:
> 
> > Cheng-Yin
> >
> > Cheng-Yin Lee wrote:
> >
> > > I believe the questions are, what does an Ethernet wire 
> support, and
> > > what should an Ethernet pseudo-wire support.
> > > "Ethernet transmission to a "multicast" IEEE-48 address 
> is in scope" is
> > > in the PWE3 charter and I believe it's in the charter for 
> the right
> > > technical reason.
> > >
> >
> > I have been mulling this over. The implicit definition of 
> an Ethernet
> > wire that has been used in the PWE3 work so far is an Ethernet
> > attachement point, ie a Cat5 cable (or AUI cable or the 
> middle leg of
> > a coax T).
> >
> > Given that none of us are suggesting unfiltered multicast, 
> that would
> > sufficient provided we can emulate everything that we want using it.
> >
> > Perhaps we should make this definition of an ethernet wire explicit
> > somewhere?
> 
> I am not sure what  is being defined above.  I don't believe 
> it's up to the
> PWE3 WG to redefine Ethernet. Ethernet has already been defined.
> In Ethernet I know, regardless of whether a node is connected 
> to a segment,
> hub or a switch (via any of the cable you mentioned) , the 
> node can transmit
> to multiple nodes.
> 
> regards
> cheng-yin
> 
> 
> > Now we get to the issue of emulating a bridged/switched network
> > (given that we agreed above that we are not doing multicast, we
> > are doing filtering/learning and therefore we are emulating one
> > or more bridges).
> >
> > Can we agree that we emulate such a network by using our ethernet
> > wire definition above and run some function in the NSP and FWRD
> > functions to complete the emulation?
> >
> > If so, that leads us to the definition of these functions and where
> > they should be defined.
> >
> > As I understand things, the protocols being defined by 
> PPVPN could be
> > used between user equipment (by making the their PE 
> function run on a
> > CE box) without explicit support from the SP. Is that correct?
> >
> > If so, then surely we should just use their work to implement such
> > functions, and end this discussion.
> >
> > However if we do not think that PPVPN are satisfying the 
> requirements,
> > then we need to document the short-commings, before 
> desciding whether
> > the work item is a PWE3 issue or a PPVPN issue.
> >
> > Have I sumarised this correctly?
> >
> > Regards
> >
> > Stewart
> >

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Mon, 11 Nov 2002 14:55:56 +0900

>the need for such emulation which I do not deny in the least).

I think the issue is what is emulated by the Ethernet wire, because
it must interwork with existing LAN/Bridge implementation, so emulated 
technology that specify conformance must be identified.

In the IEEE 802 world, "LAN segment" means the medium connection, e.g., 
1000BASE-T, between Medium Dependent Interfaces in a LAN (see section 
1.4.244 in IEEE 802.3-2002). A Repeater may interconnect similar LAN 
segments, such as 100BASE-X and 100BASE-T4 (see section 1.4.232 in IEEE 
802.3-2002). 

IEEE 802.1D-1998 and 802.1t-2001 specify Bridge architecture, MAC frame 
relay operation, Bridge protocols (such as STP, GARP, and GMRP), and
management protocol. It terminates MAC layer, then forwards an incoming
MAC frame to another or others interfaces. A Bridged LAN is a concatenation 
of individual LANs interconnected by Bridges. (see section 3.1 in 
IEEE 802.1D-1998). A LAN is a technology that provides the MAC service,
that is, a LAN segment or LAN segments interconnect through Repeater(s).

If an Ethernet wire emulates a LAN, it provides a medium dependent service,
such as 1000BASE-to-1000BASE service, and it must transparently forwards 
MAC control protocol such as PAUSE and LCAP.

However, according to section 3.16 draft-ietf-pwe3-ethernet-encap-01.txt,
the Ethernet wire does not forwards PAUSE frame, this is an evidence that
the wire terminates MAC layer, then forwards it to the other interface, 
so I think there is no choice except that the Ethernet wire emulates
a special kind of the Bridged LAN (composed by 1982-style Bridges).

Thanks,

Muneyoshi Suzuki

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 12 Nov 2002 00:02:18 -0500

Muneyoshi, Sasha, Stewart,
> technology that specify conformance must be identified.

Yes, as I posed the question before, what is an Ethernet "wire", what
should an Ethernet pseudo-wire support?
I believe we are emulating a LAN (not a physical wire or hub) or we are
allowing the "inter-connection of stations attached to separate LANs as
if they were attached to a single LAN". 

>From IEEE 802.1d:
LAN  - IEEE 802 LANs (also referred to in the text simply as LANs) are
LAN
technologies that provide a MAC Service equivalent to the MAC Service
defined in ISO/IEC 15802-1. IEEE
802 LANs include IEEE Std 802.3 (CSMA/CD), ISO/IEC 8802-4 (Token Bus),
....
Bridged LAN - The Bridged LAN created allows the inter-connection of
stations attached to separate LANs as if they were attached to a single
LAN, although they are in fact attached to separate LANs each with its
own MAC ...

As I see it :
the learning bridge provides the function to emulate a LAN and hence
should be part of the pseudo-wire emulation function (not outside of
it), and the PWE3 architecture doc may want to reflect this for Ethernet
pseudo-wire emulation.
We could say for the special case where there are only 2 devices in an
emulated LAN, we can have p2p transport of Ethernet and the learning
bridge function is null (other 802 features not related to (multipoint)
ethernet emulation may still be required, as Muneyoshi mentioned
before).
Where there are more than 2 devices in an emulated LAN, the less
convoluted way is to have Ethernet _transported_ p2p (not as p2p
Ethernet pseudo-wire/emulation) and 802.1d bridging over the (p2p)
virtual ports. I think these should be part of the Ethernet pseudo-wire
emulation function. Other 802 functions may be required as well.

Hence, I am not sure how one can argue that emulating Ethernet/a LAN is
not part of Ethernet pseudo-wire (it is also not productive to keep
arguing about this).

thanks
cheng-yin

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 12 Nov 2002 10:29:41 +0200

Cheng-Yin and all,
Please see some comments inline.
With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> Sent: Tuesday, November 12, 2002 7:02 AM
> To: [email-masked]
> Cc: Sasha Vainshtein; [email-masked]; [email-masked]; [email-masked]
> it), and the PWE3 architecture doc may want to reflect this 
> for Ethernet pseudo-wire emulation.
>
I disagree. I do not think that LAN is a special type of a wire. 
Nor do I think that the PWE3 charter says that LAN emulation is in 
the scope of this WG.
To the best of my knowledge, most LANs in operation today are
emulated using a combination of P2P "wires" and LAN-emulating
devices like hubs, bridges etc. The p2mp wires (like coax cables
with multiple T connectors) that have had, in the past, provided
LAN services, have become obsolete now and are gradually replaced.
The partitioning proposed by Stewart, where the Ethernet PWs are p2p
and emulate p2p LAN segments (as Eric has said)
and LAN functionality, if required, is provided by the Forwarder 
blocks emulating learning bridges simply reflects this fact.
> virtual ports. I think these should be part of the Ethernet 
> pseudo-wire emulation function. Other 802 functions may be 
> required as well.
>
I do not understand the (stressed) difference between
p2p Ethernet transport between virtual ports and p2p Ethernet
PW emulation. I would also like a clarification regarding
"other 802 functions" you have in mind.
I think that one issue that has been, raised (implicitly)
in this discussion, is that of Ethernet-like flow control over
an Ethernet PW. E.g., should the egress PE signal a
congestion condition it detects backwards to the 
ingress (thus emulating a PAUSE frame)? And, if yes, 
how should this indication be sent and processed?
Please note that the egress PE may use different
methods to detect a congestion condition, including,
but not limited to, ECN-based ones (see RFC 3168)
if the underlying PSN supports them, relaying
"native" PAUSE frames received from the attached CE,
monitoring its own queues etc.
> not part of Ethernet pseudo-wire (it is also not productive to keep
As I have said already, by claiming that Ethernet LAN
and Ethernet wire are not the same thing.