Subject: Comments on draft-martini-l2circuit-trans-mpls-00.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 21 Dec 1999 12:05:01 -0500

I read this draft with great interest and have a few comments.

1. There was no discussion concerning mutual encapsulation/tunneling or 
even mention of RFC 1326.

2. There was no discussion of the requirements this particular draft was 
trying to meet, or any comparison of the pluses and minuses of this draft 
to any of the other L2 tunneling mechanisms in use, such as GRE.

In addition, when MPLS is used over ATM or Frame Relay networks, there may 
be more efficient methods of encapsulation than this draft.  For example, 
in order to carry Frame Relay over ATM, it would be more efficient to use 
FRF.5 FR/ATM network interworking than FR over MPLS over ATM.

Another example is H.323-based multimedia (such as voice or video) over 
IP.  The RTP/UDP/IP headers are 20 bytes, and carrying this over ATM adds 
an additional 8 bytes for the AAL5 trailer.  The ATM Forum has a 
specification (AF-SAA-0124.000) that compresses all that down to just the 
AAL5 trailer.  This would be much more efficient than just naively sending 
RTP/UDP/IP over MPLS over ATM.

So I think what this draft really needs most is a statement of the 
requirements it is attempting to meet, and an applicability statement of 
when it could be most effectively used.

3. There is a lot more required to tunnel Frame Relay or ATM than just 
encapsulating it in a tunnel and sending the MPLS packets on their 
way.  Section 5 makes an attempt to fill this in, but needs more 
work.  Just one example of something that was missed is the necessary to 
support, for Frame Relay, bidirectional PVC status signaling across the 
tunnel so that the end-to-end status of the PVC can be properly reflected 
to the PVC endpoints.

4. In section 5.1, the egress LSR should be able to consider the value of 
the EXP field of the VC label in order to determine the value of the FR DE bit.

5. There is no attempt to map the traffic management requirements for the 
Frame Relay or ATM connections being tunneled to the tunnel itself, such 
factoring the FR CIR and EIR or the ATM bandwidth, service class, delay, 
etc. into the MPLS bandwidth requirements and other tunnel constraints.

6. The ATM AAL5 service proposed is overly restrictive, since not only does 
it not support non-AAL5 applications, it also it does not support 
applications that require the AAL5 trailer, such as Frame Relay/ATM 
interworking and H.323 over ATM, just to name two off of the top of my head.

7. Assuming an ECN bit is included in the EXP bits, then its state should 
be reflected in the FR or ATM header when the frames or cells at the 
tunnel's egress LSR.

8. I noticed that PPP is one of the protocols that can be tunneled.  This 
should be compared to L2TP, especially with regard to authentication and 
other PPP tunneling requirements.

Thanks,
Andy

________________________________________________________________________
Andrew G. Malis  [email-masked]  phone:978 952-7414  fax:978 392-2074
Lucent Technologies                 1 Robbins Road    Westford, MA 01886

---

From: Vasanthi Thirumalai <[email-masked]>
Date: Tue, 21 Dec 1999 13:21:13 -0500

Was this draft posted on this list? Did I miss it?
Could someone resend that message to me please?

Thanks,
Vasanthi

-- 
------------------------------------------------
Vasanthi Thirumalai         Phone: 732-949-3787
Lucent Technologies         Room : 2J-643
101 Crawfords Corner
Holmdel, NJ-07733
------------------------------------------------

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 21 Dec 1999 13:33:39 -0500

Vasanthi,

This was announced on the general ietf-announce list as an individual draft. 
You can get it at any Internet Draft repository, such as 
http://www.ietf.org/internet-drafts/draft-martini-l2circuit-trans-mpls-00.txt.

Cheers,
Andy

-------

---

From: Luca Martini <[email-masked]>
Date: Wed, 22 Dec 1999 22:33:55 +0000

> even mention of RFC 1326.

RFC 1326 does not apply to this encapsulation method as we are using two
different mprotocols ( MPLS and ATM , or MPLS and Frame-Relay ). 

> to any of the other L2 tunneling mechanisms in use, such as GRE.

This method is meant to allow a service provider to offer frame-relay ,
or ATM AAL5 transport services across an MPLS backbone.

> FRF.5 FR/ATM network interworking than FR over MPLS over ATM.

yes, and how is this less efficient than current Frame-Relay
implementation that use ATM as a backbone transport ?

> when it could be most effectively used.

I agree. Again, this method is meant to allow a service provider to
offer frame-relay , or ATM AAL5 transport services across an MPLS
backbone.

> tunnel so that the end-to-end status of the PVC can be properly reflected

Section 5.1 addresses this issue. In short if the Frame-Relay PVC goes
down the  VC LSP is withdrawn, and at the egress LSR, that specific
frame relay PVC is taken down. 

> the EXP field of the VC label in order to determine the value of the FR DE bit.

Assuming we are setting the EXP bits at ingress according to the DE bit.
If we are assuming that the MPLS core network does not modify the EXP
bits then the DE bit to EXP bit relationship will be the same at ingress
and egress.
Since we are transporting the Frame-Relay header the DE bit is already
set properly.

> etc. into the MPLS bandwidth requirements and other tunnel constraints.

" QoS related issues are not discussed in this draft."
but why should the backbone know about this ? 
Cir, Eir, etc. are ingress functions, which the service provider might
decide to police , or not. Policing is not part of the encapsulation,
and we do not preclude any implementation from providing CIR, or an ATM
traffic shaping function at ingress.

> interworking and H.323 over ATM, just to name two off of the top of my head.

We have left the hole internetworking question out of this draft
intentionally.
I believe that it is easier to perform the internetworking function in
the edge LSRs , and not in the network.

> be reflected in the FR or ATM header when the frames or cells at the

This work is still in progress , and it is not considered in this draft.

> other PPP tunneling requirements.

PPP or ethernet was not defined in this version of the draft. All we
have is a parameter type definition nothing more.

> Andy

Thanks,
Luca

-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Engineer, Level 3 Communications -
Broomfield, CO
[email-masked] | VE2WKR/W0 | Phone 720-888-1225 | pager
[email-masked]

---

From: Greg Waters <[email-masked]>
Date: Wed, 22 Dec 1999 18:29:23 -0500

>or ATM AAL5 transport services across an MPLS backbone.

Should your draft discuss tunneling raw ATM cells (sometimes called
"AAL0") over MPLS?  In that case, OAM F5 cells flow naturally through
the tunnel, and the tunnel end-points can more easily complete the
ATM VCC service emulation (generate alarms or propagate F5 loopback).
In addition, tunneling raw ATM cells allows ATM VPC service emulation.
Putting multiple raw ATM cells into each MPLS packet might be
desirable for efficiency.

Since ATM PVCs/VCCs are normally established bidirectionally,
a section explaining that a tunnel's end-points are common to both
directions of the emulated layer-2 VC could be helpful.  However,
tunnel mid-points could be disjoint providing that the bidirectional
emulation mechanism (keep-alive messages through the tunnel?)
works directly between the edge LSRs.

A nit: The draft used the terms "Group ID" and "Link ID" for
apparently the same concept in the LDP FEC TLV section.  --gw