Re: [PWE3] once upon an erratum

Well, actually it is 5603 ...

Y(J)S

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, May 09, 2012 15:00
To: stbryant@cisco.com
Cc: pwe3@ietf.org
Subject: Re: [PWE3] once upon an erratum

Stewart,
It is Section 9 of RFC 5063 (not 5061!)  that discusses service-delimiting modes and their mapping to the appropriate set of the PW attributes.

I apologize for the typo.

Regards,
     Sasha
________________________________________
From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Stewart Bryant [stbryant@cisco.com]
Sent: Wednesday, May 09, 2012 12:17 PM
To: pwe3@ietf.org
Subject: Re: [PWE3] once upon an erratum

Sasha

Do you have the correct reference? If so perhaps you could
point to the right section.

Stewart

Yaakov

I think that the purpose of the text as to say that the tag
may or may not be service delimiting, which I think is
demonstrably true.

Stewart

On 08/05/2012 12:20, Alexander Vainshtein wrote:
>
> Yaakov, Stewart and all,
>
> I believe that 5061 effectively supports Yaakov's point of view.
>
> My 2c,
>
> Sasha
>
> *From:*pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf
> Of *Yaakov Stein
> *Sent:* Tuesday, May 08, 2012 1:59 PM
> *To:* Stewart Bryant; pwe3@ietf.org
> *Subject:* [PWE3] once upon an erratum
>
> Stewart and all,
>
> RFC 4448 has an erratum marked "Held for Document Update by Stewart
> Bryant".
>
> This erratum (penned by Alfred Hoenes) deals with several issues,
>
> from a "subtle typo" to the misleading figure label.
>
> However, there is one issue with which I agree and which I think is
> important;
>
> but regarding which I don't recall discussion on the list.
>
> With the entire group of comments marked as "held for document update"
> rather than as "approved",
>
> I am not sure whether this issue has been agreed upon.
>
> The text in question is this :
>
> When the PE receives an Ethernet frame, and the frame has a VLAN tag,
>
> we can distinguish two cases:
>
> 1. The tag is service-delimiting. This means that the tag was
>
> placed on the frame by some piece of service provider-operated
>
> equipment, and the tag is used by the service provider to
>
> distinguish the traffic. For example, LANs from different
>
> customers might be attached to the same service provider
>
> switch, which applies VLAN tags to distinguish one customer's
>
> traffic from another's, and then forwards the frames to the PE.
>
> 2. The tag is not service-delimiting. This means that the tag was
>
> placed in the frame by a piece of customer equipment, and is
>
> not meaningful to the PE.
>
> Alfred states that
>
> The term, "service delimiting", apparently here is defined
> by the origin of the tag, not by its function.
>
> I understand where the original text comes from.
>
> In the provider provisioned model the SP doesn't trust the customer to
> properly tag the frames,
>
> and so doesn't look at tags inserted by CE devices.
>
> However, other groups (e.g., MEF) assume careful prior negotiation
>
> (of the legal kind, not the protocol kind) between customer and SP,
>
> and so the C-tag may indeed be service delimiting.
>
> More specifically, one can make the distinction between three
> "bundling" types
>
> based on the C-tag.
>
> *All-to-one means that all C-tags are taken as one "flow" or "EVC" or
> whatever,
>
> and thus the mapping to PW is independent of this tag.
>
> So here the C-tag is NOT service delimiting.
>
> *One-to-one means that each C-tag is mapped to a single EVC.
>
> So the C-tag determines the PW, and is thus service delimiting.
>
> *Arbitrary bundling means we have a general mapping
>
> of C-tags to EVCs (and so includes the previous two).
>
> In general the C-tag here too is service delimiting.
>
> (NOTE: the arbitrary and One-to-one cases are lumped together in MEF as
>
> the "bundling" case.)
>
> Do you agree with this analysis, and thus with the need to remove the
> caveat in 4448
>
> that states that C-tags can not be service delimiting ?
>
> Y(J)S
>
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please
> inform us by e-mail, phone or fax, and then delete the original and
> all copies thereof.
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3

--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3