The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Folks,

	My technical comments.

	I do not think the statement -

"Since the header following the link layer header 
 is no longer IP, the existing compression techniques 
 will not operate"

- which appears in the abstract of the ID entitled
"MPLS/IP Header Compression" has been given enough 
thought.  

	This statement points out that this draft may
be setting a precedent for how MPLS works when the
link layer needs to indicate that the data frame is
not IP (because it is MPLS) and the data encapsulated
is not standard IP (because - in this case - it is
compressed IP header).  Also, it is possible to choose 
an approach that makes this statement invalid.

	I do not think that the precedent this draft 
may set is a good one.  While the draft states that 
the alternative of using IP header compression - as
is - over MPLS was considered, I think this option
was too quickly dismissed.  

	One of the reasons it was dismissed was that 
MPLS headers do not carry packet type codes.  In 
making this decision in design of MPLS, we setup a
general requirement to define new type codes for 
applicable link layers WHEN IT IS IMPORTANT FOR AN
INTERMEDIATE LSR TO KNOW THE PROTOCOL OF THE DATA
PACKET ENCAPSULATED BY MPLS.  Hence, if we determine
that there is a need for intermediate LSRs to know
that the MPLS encapsulated packet uses IP header
compression, then we might be justified in defining
new link layer discriminators (packet type codes)
for such packets when transported over MPLS.

	This draft fails completely to justify a need
for intermediate LSRs to understand that MPLS packets
may encapsulate compressed IP headers.  In fact, the
possibility that there may be intermediate LSRs is 
not sufficiently explored, since this possibility 
implies the further possibility of needing to stack
additional MPLS labels (this is discussed below).

	If it is not important for intermediate LSRs
to understand that header compression is used, then 
one very good approach is to define extensions to a
signaling protocol such that each end of an LSP will
know that the LSP itself is being used to transport
IP-header-compressed data packets.  This alternative
does not appear to have been considered.  Yet this
is the alternative currently used most often to deal 
with LSP end-to-end requirements.  Such an approach
should be straight-forward and should have no impact
on LSRs that do not need to support this capability.

	A second reason for dismissing other approaches 
was that additional compression efficiency could be
obtained by compressing the MPLS shim header as well.
I do not see that the potential for compressing one
32 bit word justifies the proposal.  Further, I doubt
the existence of an application for multiple stacked
labels being transported across a low-speed link - 
thus it does not seem likely that the MPLS shim header 
will be much larger than 32 bits.

	Which is a segue into problems with intermediate
LSRs: the possible existence of intermediate LSRs means
that there might be a need to further encapsulate an
MPLS labeled packet by pushing on an additional label.
For example, the low-speed link might be carried in an
LSP trunk.  If an LSR is faced with the need of adding
a label to the stack of an MPLS-header-compressed packet,
how is this done?  Is there an impact if there is a
need to further stack labels as the packet is progressed
toward the core of a network?  

	I think there is an impact in the current proposal.  
I also feel certain there is not in either proposal I
would make (have made, if you read the above carefully).
I believe that - unless the current proposal can provide
a means to preclude its use across low-speed links that
are transported using LSP trunks - this proposal will
have far reaching implications on not-so-slow links.

	Hence, I feel this draft uses the wrong approach
at a very fundamental level and do not feel that it is
the approach that the MPLS working group should adopt.

--
Eric Gray


> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Thursday, July 20, 2000 11:17 AM
> To: mpls@UU.NET
> Subject: Consensus on compression
> 
> 
> Folks,
> 
> Since there clearly is confusion over whether consensus over adopting 
> 
> 	draft-ietf-mpls-hdr-comp-over-ppp-00.txt
> 	draft-ietf-mpls-hdr-comp-00.txt	
> 
> and since the minutes don't clearly indicate that there was, then we
> need to start again.  So, lets discuss see if we can reach consensus
> on the list.  If a consensus forms, we'll declare it prior to the
> meeting.  If not, we'll allocate a bit of time to discuss it there.
> 
> Note that this is not a package deal.  The two drafts should be
> considered independently (and on separate threads).
> 
> ...George
> 
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
> 
>