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

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

Ali,

Ali Sajassi wrote:
> 
> >
> >There was good support to start service interworking in the L2VPN WG
> >meeting yesterday. If this happens, clearly the encpasulation and
> >signaling parts are part of the PWE3.
> 
> If I remember correctly, there was a good support to take care of L2VPN
> scenarios with disparate interfaces and this doesn't necessarily mean
> service interworking.

MA> You can give it any name you like, I have an issue with some of
my customers and I am looking for a way to resolve it.
 
> >In my presentation, I mentioned three options:
> >a. extend FR or Ethernet to the remote PE. This is a valid solution
> >and should be supported. The problem is there are more and more
> >Ethernet/MPLS PE products out there which do not implement anything
> >about FRoMPLS, let alone FR-Ethernet interworking.
> >b. split the FR VC into multiple parallel PWs (1-to-N). I guess the
> >implementation complexity and troublshooting complications of this
> >solutions are obvious.
> >c. The PID translation between FR, PW, and Ethernet. In my view this
> >is the most straighforward solution. It does not change the
> >forwarding paradigm because it is still based on the label. It only
> >tranlates a PID in the paylod between FR and PW or FR and Ethernet.
> 
> All these scenarios plus more have been described in
> draft-sajassi-l2vpn-interworking and as  I said before it is not as simple
> as just getting PID assignment for different protocol types coming over
> disparate interfaces !!! You need to pay attention to the dependency
> between L3 protocol and the underlying L2 transport and its ramification.

MA> I agree we need to consider these. Though, the dependency of the
L3 protocol on the type of L2 interface is an orthogonal issue to
the encapsulation one. You need to address the former no matter how
you perform the encapsulation.
By the way, draft-sajassi-l2vpn-interworking provides a good
coverage of the issues. Well done.
 
> -Ali

---

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

Ali,

Ali Sajassi wrote:
> 
> Mustapha,
> 
> As I mentioned during the meeting and as mentioned in my draft, there is a
> L3 dependancy on L2 interfaces and therefore supporting multiple protocols
> between two heterogeneous ACs is not as simple as just coming up with PID
> assignment. In your example of FR and Ethernet interfaces having IP and
> IS-IS on top of them, the IP requires ARP mediation and IS-IS simply
> doesn't work in your example - take a look at arp-mediation draft.
> 
> -Ali

MA> Thanks for pointing this out. I saw this and I also looked into
the referenced document, draft-ietf-isis-igp-p2p-over-lan-02.txt. I
am very interested in this topic. 

> At 08:05 AM 7/16/2003 -0400, Mustapha Aissaoui wrote:
> >Luca,
> >a MPLS label cannot indicate that both IP and IS-IS/CLNP are being
> >carried in the PW. You would need either to extend FR (or Ethernet)
> >to the remote PE or create multiple PWs for each payload in the
> >terminated FR VC.
> >The first solution is valid but the issue is that you typically do
> >not expect all remote PE's (which have only GigE and MPLS
> >interfaces) to understand FRoMPLS and RFC 2427. The multiple PWs per
> >FR VC is not practical. So, the translation of the FR and Ethernet
> >PIDs to the PW PID allows a suitable solution.
> >
> >Mustapha.
> >---------------
> >Luca Martini wrote:
> > >
> > > and what does this add that cannot be indicated by an MPLS label ?
> > >
> > > Luca
> > >
> > > Mustapha Aissaoui wrote:
> > > > George,
> > > > I just send an updated slide set to Danny for my presentation this
> > > > afternoon of draft-aissaoui-extended-pid. I added an example
> > > > application where the translation of PID between FR, PW, and
> > > > Ethernet is very useful. The main point is that in many of the
> > > > installed base of L2 VPN, FR and ATM VCs carry more than one user
> > > > payload (e.g., IP and IS-IS/CLNP). In those cases only, a
> > > > translation of PID is useful if one one wants to have dissimilar L2
> > > > access over a PW (e.g., FR-MPLS-Ethernet).
> > > >
> > > > I hope Danny will upload it soon so that everone will have a chance
> > > > to see it before the meeting this afternoon.
> > > >
> > > > Mustapha.
> > > > ----------
> > > > George Swallow wrote:
> > > >
> > > >>>5.4.4. MPLS Payload Identifier
> > > >>>
> > > >>>
> > > >>>    If technical considerations result in a PW control word that may
> > > >>>    alias an IP packet, the control word SHOULD be preceded by an MPLS
> > > >>>    payload type identifier.
> > > >>>
> > > >>
> > > >>What problem does this solve that just adding four bytes to your
> > > >>header (in the putative case) doesn't solve?
> > > >>
> > > >>...George
> > > >>
> > > >>========================================================================
> > > >>George Swallow             Cisco Systems                  (978) 936-1398
> > > >>                           1414 Massachusetts Avenue
> > > >>                           Boxborough, MA 01719
> > > >
> > > >
> > > > _______________________________________________
> > > > 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: "Serbest, Yetik" <[email-masked]>
Date: Tue, 5 Aug 2003 10:35:00 -0500

Why are your customers so adamant on not changing their encapsulations? Is
it because their CPE does not support bridged encapsulations (like old
FRADs)?

-----Original Message-----
From: Mustapha Aissaoui [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2003 8:47 AM
To: Ali Sajassi
Cc: [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4

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: "Serbest, Yetik" <[email-masked]>
Date: Wed, 6 Aug 2003 08:56:19 -0500

You raised that issue as a reason. What is the degree of configuration
change you accept? To make OSPF work properly you have to configure the
Ethernet interface as point-point. For IS-IS, extended PID does not work.
Are you going to ask your customers to use OSPF? Ali's proposal is
architecturally more sound to me. In addition, I really don't think the
amount of work to be done by a PE is that different in both cases, i.e.,
extended PID vs. multiple VCs.

Thanks,
yetik

-----Original Message-----
From: Mustapha Aissaoui [mailto:[email-masked]] 
Sent: Wednesday, August 06, 2003 8:10 AM
To: Serbest, Yetik
Cc: [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4

Yetik,
the word "adamant" is maybe strong. I heard a couple of issues: CPE/CLE
capabilities is one of them indeed. The other one is related to the change
of configuration required on many of the existing sites.

In any case, whether a bridge encapsulation is used or not is orthogonal to
the the way a FR VC is interworked with a point-to-point Ethernet interface.
The main issue is how to carry multiple user payloads across FR-VC to PW to
Ethernet interface.

Regards,
Mustapha.
-----------
"Serbest, Yetik" wrote

> Why are your customers so adamant on not changing their 
> encapsulations? Is it because their CPE does not support bridged 
> encapsulations (like old FRADs)?
>
> > >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.
> >
> > 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
> > 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.
>
> 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.
>
> > 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.
>
> 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
> > >encapsulation and signaling from his draft such that we progress 
> > >the work here in PWE3 (assuming the charter is modified). The other 
> > 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 !!!
>

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 06 Aug 2003 10:20:47 -0400

Yetik,
the IS-IS example I have shown in my presentation in Vienna was not for an
enterprise type network. It was for an ISP buying PoP connectivity through
another service provider. There is a way to make IS-IS work without a bridged
encapsulation. It is described in Section 9.3.1.1 of
draft-lee-ppvpn-hybrid-vpls-01.txt.

Again, whether you perform a PID translation or multiple PWs is orthogonal to
how IS-IS is carried. Even if you use bridge encapsulation for IS-IS, you are
dealing with a FR VC carrying multiple payloads (IP routed and IS-IS bridged).

Regards,
Mustapha.
-----------

---

From: "Serbest, Yetik" <[email-masked]>
Date: Fri, 8 Aug 2003 08:44:57 -0500

As far as I can tell, what you point me to can not work for ISIS, right?
Because ATM/FR side does not include MAC address in its Hello PDU. So, there
is no way to proxy ARP. Am I missing something?

Thanks,
Yetik

-----Original Message-----
From: Mustapha Aissaoui [mailto:[email-masked]] 
Sent: Wednesday, August 06, 2003 9:21 AM
To: Serbest, Yetik
Cc: [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4

Yetik,
the IS-IS example I have shown in my presentation in Vienna was not for an
enterprise type network. It was for an ISP buying PoP connectivity through
another service provider. There is a way to make IS-IS work without a
bridged encapsulation. It is described in Section 9.3.1.1 of
draft-lee-ppvpn-hybrid-vpls-01.txt.

Again, whether you perform a PID translation or multiple PWs is orthogonal
to how IS-IS is carried. Even if you use bridge encapsulation for IS-IS, you
are dealing with a FR VC carrying multiple payloads (IP routed and IS-IS
bridged).

Regards,
Mustapha.
-----------
"Serbest, Yetik" wrote:

> change you accept? To make OSPF work properly you have to configure 
> the Ethernet interface as point-point. For IS-IS, extended PID does 
> not work. Are you going to ask your customers to use OSPF? Ali's 
> proposal is architecturally more sound to me. In addition, I really 
> don't think the amount of work to be done by a PE is that different in 
> both cases, i.e., extended PID vs. multiple VCs.
>
> Thanks,
> yetik
>
> the word "adamant" is maybe strong. I heard a couple of issues: 
> CPE/CLE capabilities is one of them indeed. The other one is related 
> to the change of configuration required on many of the existing sites.
>
> In any case, whether a bridge encapsulation is used or not is 
> orthogonal to the the way a FR VC is interworked with a point-to-point 
> Ethernet interface. The main issue is how to carry multiple user 
> payloads across FR-VC to PW to Ethernet interface.
>
> Regards,
> Mustapha.
> -----------
> "Serbest, Yetik" wrote
>
> > > >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 
> > > >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.
> > >
> > > >the work here in PWE3 (assuming the charter is modified). The 
> > > >other interworking aspects in his draft can be progressed in the 
> > > >l2vpn WG.
> > >
> > > 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 !!!
> >

---

From: David Watkinson <[email-masked]>
Date: Fri, 08 Aug 2003 14:32:42 -0400

Yetik,

The issue here is how to encapsulate ISIS to carry it on PW's.  Assume that the
customer of the provider has a mixture of ATM routed encapsulation, FR routed
encapsulation and PPP AC's running IP and ISIS only.  I'll deal with adding
bridged encapsulation and ethernet AC's later.  There are several options:
#1 - over ATM using draft-ietf-pwe3-atm-encap and service interworking FR and
PPP to ATM
#2 - over IP using draft-ietf-isis-wg-over-ip for the ISIS traffic.  This may
have to be interworked by the PE if the CE router can not support it.
#3 - over Ethernet by stripping the ATM,FR,PPP and adding an 18-byte MAC
header.  There isn't likely going to be valid MAC addresses to use with these
AC's so fake MAC addresses may be needed.
#4 - over PW PID by stripping the ATM,FR,PPP and adding a 4-byte PW PID.

Solution #2 is not likely to take off as this draft is not implemented by many
vendors.

Solution #4 seems to be the best for efficient operation.

The use of a secondary PW for carrying the IP traffic is an independant decision
and only makes sense when coupled with choice #3 in order to reduce bandwidth
utilitization.  It seems to me that the management overhead and additional
signalling of dealing with an additional PW per ISIS adjacency is very expensive
compared to combining them using one of the four solutions above.

When adding bridged encapsulation or ethernet AC's (e.g. an ethernet AC to a FR
AC), the ISIS link can be configured as point-to-point or broadcast.  This
configuration needs to be consistent across both CE's.

When it is point-to-point (i.e. only one CE device on the ethernet end), the
procedures in draft-ietf-isis-igp-p2p-over-lan will apply.  Any of the four
solutions above apply in this case, although Solution #3 will no longer need
fake MAC addresses.

When it is broadcast, there can be multiple CE routers on the ethernet AC.  The
preferred route in this particular case is to change the FR AC to bridged
encapsulation and use ethernet encapsulation through the pseudowire.  This will
allow the FR attached CE to properly participate when presented with packets
with the three multicast MAC addresses AllISs, AllL1ISs, and AllL2ISs.  If the
FR AC is not changed to bridged encapsulation, the ethernet attached PE will
need to assume that all ISIS packets received across the pseudowire should be
prepended with the AllISs destination MAC or dig into the packet to determine
the MAC to use based on the packet type.

Dave.
-----------------------

---

From: "Serbest, Yetik" <[email-masked]>
Date: Fri, 8 Aug 2003 14:23:37 -0500

David,

The problem raised was that your customer does not want to change the
encapsulation. Hence, you say "If the FR AC is not changed to bridged
encapsulation, the Ethernet attached PE will need to assume that all ISIS
packets received across the pseudowire should be prepended with the AllISs
destination MAC or dig into the packet to determine the MAC to use based on
the packet type". Then I would recommend you ask your customer to read this,
and I am pretty sure they would volunteer to change their configuration.

The bottom-line is that in scenarios with disparate attachment circuits (one
side Ethernet and the other is ATM/FR), bridged interworking is a simple and
clean approach.

Thanks,
yetik

-----Original Message-----
From: David Watkinson [mailto:[email-masked]] 
Sent: Friday, August 08, 2003 1:33 PM
To: Serbest, Yetik
Cc: 'Mustapha Aissaoui'; [email-masked]
Subject: Re: [PWE3] draft-ietf-pwe3-arch-04.txt section 5.4.4

Yetik,

The issue here is how to encapsulate ISIS to carry it on PW's.  Assume that
the customer of the provider has a mixture of ATM routed encapsulation, FR
routed encapsulation and PPP AC's running IP and ISIS only.  I'll deal with
adding bridged encapsulation and ethernet AC's later.  There are several
options: #1 - over ATM using draft-ietf-pwe3-atm-encap and service
interworking FR and PPP to ATM #2 - over IP using draft-ietf-isis-wg-over-ip
for the ISIS traffic.  This may have to be interworked by the PE if the CE
router can not support it. #3 - over Ethernet by stripping the ATM,FR,PPP
and adding an 18-byte MAC header.  There isn't likely going to be valid MAC
addresses to use with these AC's so fake MAC addresses may be needed. #4 -
over PW PID by stripping the ATM,FR,PPP and adding a 4-byte PW PID.

Solution #2 is not likely to take off as this draft is not implemented by
many vendors.

The use of a secondary PW for carrying the IP traffic is an independant
decision and only makes sense when coupled with choice #3 in order to reduce
bandwidth utilitization.  It seems to me that the management overhead and
additional signalling of dealing with an additional PW per ISIS adjacency is
very expensive compared to combining them using one of the four solutions
above.

When adding bridged encapsulation or ethernet AC's (e.g. an ethernet AC to a
FR AC), the ISIS link can be configured as point-to-point or broadcast.
This configuration needs to be consistent across both CE's.

When it is broadcast, there can be multiple CE routers on the ethernet AC.
The preferred route in this particular case is to change the FR AC to
bridged encapsulation and use ethernet encapsulation through the pseudowire.
This will allow the FR attached CE to properly participate when presented
with packets with the three multicast MAC addresses AllISs, AllL1ISs, and
AllL2ISs.  If the FR AC is not changed to bridged encapsulation, the
ethernet attached PE will need to assume that all ISIS packets received
across the pseudowire should be prepended with the AllISs destination MAC or
dig into the packet to determine the MAC to use based on the packet type.

Dave.
-----------------------
"Serbest, Yetik" wrote:

> As far as I can tell, what you point me to can not work for ISIS, 
> right? Because ATM/FR side does not include MAC address in its Hello 
> PDU. So, there is no way to proxy ARP. Am I missing something?