Subject: Re: [PWE3] Re: Bridge or

From: "Cheng-Yin Lee" <[email-masked]>
Date: 6 Dec 2002 16:48:59 -0500

Danny,

> > We should also clarify other NSP functions such as handling CRC errors,
>   > framing errors, runt conditions, etc.., and equally, PW functions that
>   > result in PW "generalized bit errors" (e.g., out-of-order packets, packet
>   > loss, etc..), as Akiva suggests.
>
>   I'm very confused now. The above functions are indispensable for Ethernet
>   frame transport over GRE/LSP tunnel. Nevertheless, you claim that the NSP
>   is not the part of the PW.......
>
>   I would like to suggest to carefully sort our functionalities of PW model
>   from viewpoint of protocol architecture.
>

I am puzzled too. Where will the above so-called NSPs functions be specified?

BTW,  if you agree with Juergen, it's option (a),  not (b).  In Option (a), which
I believe is the technically correct thing to do in PWE3, we can use IEEE specs
in some of the emulation blocks as well, it doesn't mean PWE3 need to specify
them.

thanks
cheng-yin

Muneyoshi Suzuki wrote:

> Danny,
>
> > It's important to remember that it's not necessarily a goal for PWE3
> > to provide exact faithfulness to that of the native protocol (the FW
> > document suggests PWE3 emulates "essential attributes" of a service).
>
> Yes, but limitation must be addressed in the applicability statement,
> so semantics must be clarified.
>
> > As such, with keeping the above in mind, Juergen is correct in stating
> > that "PWE3 defines the transport of L1/L2 client signals over a PSN
> > (paraphrased)".
>
> Agreed.
>
> > I believe the latter of your concern here was regarding the term used
> > to define the "native protocol" (or "service") itself and do agree
> > aligning terminology certainly makes sense.
>
> Exactly.
>
> > You folks were OK with
> > "(Ethernet) LAN Emulation" or "Bridged (Ethernet) LAN Emulation", just
> > not "Bridge Emulation", correct?  I think we can work with this...?
>
> I think the PW Ethernet reference configuration defined in section 2
> can be termed Bridged (Ethernet) LAN Emulation, from viewpoint service
> customers.
>
> > That being said, as Eric stated, while a PW does include NSP functionality
> > for the service that's being emulated, the NSP is NOT part of the PW.
>
> As Cheng-Yin pointed out, the scope of draft-ietf-pwe3-ethernet-encap-01.txt
> is one of issues.
>
> According to the abstract, this draft discuss encapsulation of
> Ethernet/802.3 PDUs within a pseudo-wire.
>
> >Abstract
> >   existing PSN to offer ethernet services. This document addresses the
> >   encapsulation of Ethernet/802.3 PDUs within a pseudowire, and issues
> >   associated with the point-to-point emulation of ethernet within a PW.
>
> But, the draft mainly consists of section 3 that is titled "Requirements
> for Ethernet Pseudo-Wire Emulation". It seems to me, this section does
> not discuss requirements, but if it is really requirements, this section
> should be entirely moved to the PWE3 requirements document.
>
> I think requirements mean description of conditions that should be
> satisfied by a solution. However, it seems to me section 3 addresses
> implementation model and technical specification. So, if the draft
> specifies PW protocol, it should focus PW protocol only, NSP and
> CE-to-CE service are out scope of the draft.
>
> If the draft specifies PW protocol and CE-to-CE service scenario using the
> PW, these must be described separately. And it seems to me, NSP does not
> emulate anything; for me it consists of MAC entity that terminates CE-PE link
> and MAC relay entity, but if it emulates something, emulated entity that
> is specified in existing standard or recommendation must be clarified.
>
> > Now, back to the first issue:
> > I believe the initial concerns were triggered by Section 3.1.6
> > of the Ethernet encapsulation draft, where it states that the PAUSE
> > frames MUST NOT be transmitted across a PW (paraphrased).  If I'm
> > not mistaken, that text was added quite a while ago in order to
> > suggest [to naive implementers] that it doesn't make sense to forward
> > IEEE802 flow-control frames across a PW/PSN.
>
> I don't think "forwarding PAUSE frame across PW does not make sense",
> because, a PW is not Ethernet, so PAUSE frame is undefined in that section.
>
> > Being that the "MAC Entity", which resides within the NSP function,
> > provides PAUSE frame termination, perhaps removing the current text
> > and clarifying by employing additional NSP-specific terms will ease
> > your concerns?  If so, perhaps you could provide some text here?
>
> I think it depends on the scope of the draft. But if needed a small note
> is sufficient, e.g.,
>
> Note that PAUSE frame is undefined on the PW, because it is not Ethernet.
>
> > We should also clarify other NSP functions such as handling CRC errors,
> > framing errors, runt conditions, etc.., and equally, PW functions that
> > result in PW "generalized bit errors" (e.g., out-of-order packets, packet
> > loss, etc..), as Akiva suggests.
>
> I'm very confused now. The above functions are indispensable for Ethernet
> frame transport over GRE/LSP tunnel. Nevertheless, you claim that the NSP
> is not the part of the PW.......
>
> I would like to suggest to carefully sort our functionalities of PW model
> from viewpoint of protocol architecture.
>
> > And we're certainly not providing the "medium connection", between
> > "Medium Dependent Interfaces"!
>
> I fully agree with this. Therefore, the PW Ethernet reference configuration,
> defined in section 2, does NOT provide LAN emulation or emulated LAN
> service to customers.
>
> Thanks,
>
> Muneyoshi Suzuki
> Nippon Telegraph and Telephone Corp.
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3