Subject: Re: draft-ietf-pwe3-arch-04.txt section 5.4.4

From: Mustapha Aissaoui <[email-masked]>
Date: Tue, 05 Aug 2003 09:46:54 -0400

Ali,

Ali Sajassi wrote:
> 
> At 02:53 PM 7/28/2003 -0400, Mustapha Aissaoui wrote:
> >Eric,
> >draft-sajassil2vpn-interworking-01.txt has a wider scope than mine since
> >it goes
> >into some of the details of the interworking. In terms of the
> >encapsulation, Ali
> >proposes to use the PID field similar to the one used in GRE encapsulation.
> 
> The draft discusses two approaches:
> a) using multiple PWs
> b) using multi-protocol PW
> 
> and discusses the pros/cons of each. It also clearly states an example
> where the user can just get away with just two PWs  for multi-protocol
> support (one for IP and another for non-IP based on Ethernet/bridged encap)
> by configuring IP traffic as routed and all other non-IP traffic as bridged
> encap.
> 
> At this point, I think the multiple PWs scheme is sufficient - one for IP
> and the other for non-IP traffic which is bridged encapsulated. And we
> don't need to define a new multi-protocol PW unless it is shown otherwise.

MA> I have issues with the 1-N VC-to-PW which I described in my
earlier emails. Furthermore, I do not expect all my customers to go
and change their encapsulations in their many sites to bridged type
unless absolutely required.
 
> >The reason why this is not sufficient is because many protocols are carried in
> >RFC 2427 and 2684 by appending the organization unique identifier (OUI) to the
> >payload. This is certainly the case of the IEEE 802.1 MAC types and private
> >organization protocols. When Andy and I looked into the best way to structure
> >the PID, we wanted to make sure we continue to support these and to limit the
> >number of combinations possible to represent a single protocol.
> 
> Are you trying to re-invent FRF8.1 !!!
> If you look at the draft closely, it says that for full ATM-FR
> interworking, standard FR8.1 is recommended by extending one PW to another
> side. And for the sub-set one can use the two-PW scheme.
> Also if one wanted to use multi-protocol PW, then GRE-based PID is
> sufficient since if you take a look at the FRF8.1, the LLC/SNAP field for
> the Ethernet/bridged, IP, IPv6, ISIS, ESIS, CLNP, etc is fixed and thus you
> don't need to send them over the PW each time.

MA> In fact, we made sure that most protocols required only a single
word header in draft-aissaoui. This is the case of IP, IPv6, ISIS,
ESIS, and CLNP. Only those protocols which require a OUI (e.g., MAC
Types and Private Protocols) add a SNAP field and thus a 2-word
multiprotocol header. 
 
> >What I would like to propose to Ali is to separate out the encapsulation and
> >signaling from his draft such that we progress the work here in PWE3 (assuming
> >the charter is modified). The other interworking aspects in his draft can be
> >progressed in the l2vpn WG.
> 
> As I mentioned, at this point I think the use of multiple PWs is sufficient
> and if it is shown that a new multi-protocol PW is needed, then still I
> think GRE-based is both sufficient and efficient since we don't want to add
> a fixed LLC/SNAP header to each packet knowing that 99% of them don't
> require it !!!

MA> Where do you see LLC/SNAP in my draft??
 
> -Ali
> 
> >Thanks for the interesting exchange.
> >
> >Mustapha.
> >-----------

---

From: Ali Sajassi <[email-masked]>
Date: Wed, 06 Aug 2003 14:57:42 -0700

>unless absolutely required.

If the issue is with notification of far-end AC and/or the reflection of AC 
status into PWs and vise versa, then this can be done in a number of ways 
(either through the use of control plane or data plane). And when talking 
about interworking of different protocols over the disparate ACs, then it 
is important to note that it is not simply just the question of 
encapsulation and PID. Furthermore, your customers probably will be willing 
to change the config in some of their sites than risking their protocols 
not working at all :-)

>Types and Private Protocols) add a SNAP field and thus a 2-word

I would encourage you to go over different scenarios for disparate ACs and 
try to see:
a) what are all different protocols that can be carried over them
b) what are the dependencies of these protocol to underlying L2 media
c) how can you interwork these different protocols
d) what is the common denominator approach among them
Once you do that, you can see that there are more issues than just defining 
a PID.
So in short, before requiring a Multi-protocol PW, the need for such PW 
needs to be clearly justified in the context of the applicable scenarios. 
At this point, I think the existing PWs plus the addition of IP PW should 
be enough unless it is shown otherwise.

>MA> Where do you see LLC/SNAP in my draft??

I guess it was your colleague Jeremy who at one point proposing that :-)

-Ali

---

From: Mustapha Aissaoui <[email-masked]>
Date: Fri, 08 Aug 2003 14:11:02 -0400

ALi,

> to change the config in some of their sites than risking their protocols

MA> I mentioned a number of issues with the 1-to-N VC-to-PWs. Let me
repeat them here for the sake of progressing the discussion:
a. OAM of a single VC which paylod is split over multiple PWs has
not been proven to work.
b. Reflecting the status of the entire VC based on the status of
individual PWs is not obvious to me. What do you do when your
bridged-encap PW is down while your routed-encap PW is still up.
What is the status of the FR VC?
c. Transparency of the L2 service is lost. Basically this solution
messes-up with the user payload. It splits user packets arbitrarily
based on received FR-PID and they are received in the far-end in an
arbitrary order because of the delay differential across multiple
independent PWs. Unless you are thinking of building something as
sophisticated as Inverser Multiplexing over ATM (IMA) or multilink
Frame Relay with a per-VC sequence number mechanism that spans
multiple PWs.

> be enough unless it is shown otherwise.

MA> Going over different scenarios for disparate ACs is not a
theoretical exercise to me. Each customer is a case of its own. In
some cases, my customer does not know much about what his customers
carry over the FR VC today (remember this FR service is a L2
transparent service). This is why the L2 dependency issues have to
be resolved customer by customer. I do not think is something that
can realistically be standardized. However, the PID translation and
the signaling of the PW can be.

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 11 Aug 2003 13:07:55 -0700

>What is the status of the FR VC?

There are two cases to consider:
a) when a PW fails and you need to notify the corresponding AC(s)
b) when one AC fails, and you need to notify the other AC
Considering the scenarios that we have been discussing (ATM/FR to 
Ethernet), there is currently no LMI for Ethernet end of it. So if a PW 
fails, the ATM/FR end of it needs to get notified only. And if an ATM/FR VC 
fails, there is no LMI to convey the failure to the Ethernet side of it. 
However, if we assume that one day we will have a LMI for Ethernet, then we 
can use the TLV defined in the draft-shah-control-protocol-extension to 
convey the status of one AC to another side for case (b) above.
And for case (a) above, the status is reported to the AC upon failure of 
any one of the N PWs (typically only 2 PWs). In other words, as soon as one 
of the PWs associated with that AC has failed, an alarm is indicated to 
that AC and there is no need to do anything else with the traffic on the 
other PWs - this is consistent with existing FR and ATM procedure where 
alarms get generated independently from the DLCI/VC customer traffic.

>Frame Relay with a per-VC sequence number mechanism that spans

Lets not confuse different traffic flow in here. The IP flow is independent 
from Apple Talk or IPX flows and each flow in delivered in order and each 
flow will experience consistent delay because all the packets in each flow 
take exactly the same path through the network. And that is different from 
different flows taking different path.
BTW, if you are concern about transparency of L2 protocols, then you should 
be concern about interception of the protocol messages and injection of new 
messages that you were referring to previously !!!

>the signaling of the PW can be.

This is interesting !!! You are saying that your customer doesn't know what 
his customer is carrying over FR but you are trying to come up with the PID 
assignment for those protocols irrespective of how those protocols can be 
handled between different disparate interfaces (e.g., between Ethernet 
broadcast interface and PtP ATM/FR interface). What I am saying is that you 
cannot just simply go and do the same PID assignment as we have in FR-ATM 
service interworking and assume that everything will work just dandy. There 
is a dependency in here and you need to factor that in first. Let me put it 
in a different way for you, for every protocol that you want to assign a 
PID for, you need to see what type of dependency it has on broadcast v.s. 
PtP media and how to handle this dependency or else you will have many 
unhappy customers :-)

I will be on vacation this week and if this stuff is still not clear, then 
we can talk more next week if needed.

-Ali

---

From: Mustapha Aissaoui <[email-masked]>
Date: Tue, 12 Aug 2003 11:02:30 -0400

Ali,

Ali Sajassi wrote:

[snip] 

> broadcast interface and PtP ATM/FR interface). 

MA> it is interesting, indeed. You seem to like extrapolating from
what I say. The point here is that each customer is a special case
and there is work to be done with their customers to make sure that
their current service is not affected when this type of interworking
is introduced. This includes the resolution of the L3 dependency on
L2 media issues and the identification of the end-user protocols.
Whether you identify them using a label as in your 1-to-N VC-to-PWs
or a PID is orthogonal to the L3/L2 dependency.

>What I am saying is that you

MA> So, what is the point you are trying to make? You have been
repeating this over and over again. I have been trying to explain
that the L3 dependency on Layer 2 media is an orthogonal issue to
the way the multiple payloads are carried over MPLS. Whether you
choose Option 1 (extend FR or Ethernet to the remote PE), Option 2
(1-to-N VC-to-PWs), or Option 3 (PID translation), you have to
resolve these issues.