The MPLS WG Archive

["Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>]

Colin,

Actually, these comments are based on the -02 version.

/L-E


> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: den 27 januari 2005 19:29
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: mpls@ietf.org; IETF AVT WG; rohc@ietf.org
> Subject: Re: [AVT] [mpls] Comments
> ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt
> 
> 
> Lars-Erik,
> 
> I notice that the -02 draft is available, but that these 
> comments are  
> based on the -01 version. Do the changes in the -02 version address  
> your concerns?
> 
> Colin
> 
> 
> 
> On 27 Jan 2005, at 16:03, Lars-Erik Jonsson (LU/EAB) wrote:
> > MPLS-HC folks,
> >
> > I've now looked into the MPLS-HC solution draft as well as the
> > mail exchanges between Magnus and Jerry. The problems I see with
> > the draft are very similar to those pointed out by Magnus. However,
> > in an attempt to avoid getting too influenced by Magnus comments
> > I will make my points purely based on my own reflections from the
> > draft, and then from that refer to the discussion between Magnus
> > and Jerry.
> >
> > Overall document structure and purpose
> > --------------------------------------
> > On a high level, I think this MPLS-HC document should be about
> > three things:
> > 1) Negotiation of use, i.e. setup signalling
> > 2) Encapsulation, i.e. how to send HC-packets over MPLS
> > 3) Operation, i.e. considerations for the actual 
> compression scheme(s),
> >   e.g. how to implement the scheme(s) to be able to handle 
> reordering
> >
> > 1-2 are addressed in the draft, while 3) is not, although it is
> > essential as an ordinary implementation of the existing HC schemes
> > would e.g. not necessarily work well enough in case of reordering.
> >
> > I also strongly believe this MPLS-HC mapping solution should cover
> > the currently available HC schemes, IP-HC, CRTP, eCRTP, and ROHC.
> > I would not say we have to make it totally generic for *any* HC
> > scheme, as I do not think we can cover up for future solutions.
> > RFC 3544 (i.e. RFC 2509bis), which provides 1) and 2) for IP-HC,
> > CRTP, and eCRTP, as well as RFC 3409, which do the same for ROHC,
> > could be used as a basis for this work. The similarities in how to
> > solve 1), 2), and 3) for existing HC schemes should be dominating
> > rather than the differences.
> >
> > By the way, could we please avoid the terminology 
> "control/data plane".
> >
> >
> > Context multiplexing within an LSP, why signalling?
> > ---------------------------------------------------
> > The second main concern I have is the same one as Magnus expressed,
> > about the multiplexing, which seems to require signalling that I
> > can not see the point of. As I know nothing about the details
> > of MPLS, my question from reading the draft was simply why there
> > would have to be any signalling for picking a CID value, existing
> > HC schemes assume the compressor does this without any signalling.
> > The draft just talks about "...to signal the SCIDs...", without
> > explaining the meaning of this.
> >
> > I do not exactly understand the underlying MPLS problem that Magnus
> > talked about that might be the motivation for having to do 
> CID tricks,
> > but I agree with his concerns about this approach, which seems to
> > require signalling for each new packet stream, and also contradicts
> > the way existing HC schemes handle CID assignment. In any case, the
> > draft should explain better the motivations behind solutions like
> > this.
> >
> > For the negotiation & encapsulation I would strongly recommend using
> > RFC 3544 and RFC 3409 as a basis, and clearly highlight potential
> > deviations from the solutions used in these RFC's, that would help
> > to get more constructive involvement from the HC folks in this work.
> >
> > On the CID handling question, I also noticed the text about how to
> > free up CID. I am not sure what the purpose of that is, but 
> this also
> > represents a deviation from how existing HC schemes are defined.
> > Looking at packets not belonging to the flow (e.g. SIP messages)
> > also seems like a not very desirable approach, in my mind.
> >
> >
> > What creates a feedback channel?
> > --------------------------------
> > Is the LSP per definition bidirectional, or are LSP's always set up
> > as pairs, one in each direction? If we talk about multiple LSP's,
> > there must be an exact 1-1 mapping, or there must be a way to create
> > that binding between them.
> >
> >
> > eCRTP packet type identification
> > --------------------------------
> > Inconsistency, first paragraph of 2.2 talks about a 4-bit 
> packet type,
> > while the second paragraph says a one-octet PT ID is used. In the
> > figure, I wonder what the first octet of zeros is, not really
> > explained. "Defined by PPP Data Link Layer Protocol" means?
> >
> >
> > HC object formats
> > -----------------
> > This section was very confusing to me. First, the text talks about
> > intermediates that do not understand HC and could drop the object.
> > My question is, should not the solution be transparent to  
> > intermediates,
> > i.e. compression should be possible between ingress and 
> egress without
> > any knowledge in the notes in between? Why should it at all concern
> > intermediates?
> >
> > Further, I have a hard time commenting on the content as the fields
> > in these objects are not described. There should be explanations
> > after the figures.
> >
> >
> > Operations
> > ----------
> > For the operations part, the draft currently says nothing, while we
> > know there are at least concerns related to reordering. The 
> ROHC over
> > reordering draft can be a useful source for information in 
> that area,
> > as well as the eCRTP evaluation I made the list aware of 
> earlier today.
> > http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering 
> > -01.txt
> > http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf
> >
> >
> > Summary
> > -------
> > I thus suggest that the overall purpose of this document 
> (to be adopted
> > as a WG document) should be to create a HC mapping for 
> MPLS, covering
> > the HC schemes we currently have, similar to RFC 3544 and 3409. It
> > should address negotiation (setup), encapsulation, and 
> potential issues
> > with operation of each HC scheme.
> >
> >
> > I'll do my best to support this work from an HC perspective.
> >
> > Cheers,
> > /L-E
> >
> >
> >> -----Original Message-----
> >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]
> >> Sent: den 22 december 2004 22:30
> >> To: IETF AVT WG; rohc@ietf.org; mpls@ietf.org
> >> Subject: [AVT] [mpls] Comments
> >> ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt
> >>
> >>
> >> Hi,
> >>
> >> Sorry for the crossposting, however this is something that I
> >> think needs
> >> to be generally discussed between all 3 WGs. To me it 
> looks like the
> >> proposed solution for VoIP header compression across an 
> MPLS network
> >> contains a problematic demultiplexing mechanism. I don't 
> think people
> >> has realized the issues with the proposed mechanism due to lack of
> >> communication between the header compression and MPLS folks.
> >> If it is my
> >> lack of knowledge please educate me, and the others. I 
> would request
> >> that people providing input in this discussion is overly
> >> explaining as
> >> education seems necessary.
> >>
> >> The current draft is available at:
> >> http://www.watersprings.org/pub/id/draft-ash-avt-ecrtp-over-mp
> >> ls-protocol-01.txt
> >> it should also be available in the IETF repository if it
> >> hasn't expired.
> >>
> >> The header compression mechanisms such as CRTP and ROHC to my
> >> understanding assumes that they have a lower link layer 
> that carries
> >> their compressed messages between compressor and
> >> decompressor. This is
> >> due to that they are intended to be used with only a single
> >> link between
> >> the compressor and decompressor. In the case of CRTP, it 
> also assumes
> >> that the link-layer can also provide the with identification of the
> >> packet types, while ROHC makes this identification internally.
> >>
> >> The MPLS network uses one or more labels in the transport between
> >> ingress and egress from the MPLS network. Due to the possible
> >> relabeling
> >> in the middle of the network, it can't be generally assumed
> >> that packets
> >> arriving with the same label comes from the same ingress 
> point. This
> >> makes the label not sufficient to identify the ingress for
> >> the egress,
> >> thus not making labels equal to a link.
> >>
> >> The proposed solution has thought of the above MPLS problem
> >> and proposes
> >> that one uses the setup signalling to allow the 
> decompressor point to
> >> select which parts of its context identifier (SCID) space
> >> that belongs
> >> to different ingress points that arrives over the same label.
> >> However my
> >> understanding is that this definitely not without problems for the
> >> header compression mechanisms. I would like the header
> >> compression guy
> >> to clarify what problems that would arise from such a solution. One
> >> thing I definitely can see would be an issue, the proposed
> >> change would
> >> prevent MPLS HC to use any standard implementation of the HC
> >> mechanism used.
> >>
> >> I would also like to point out that the Header Compression 
> mechanism
> >> needs a return path from the decompressor mechanism. However
> >> the draft
> >> does not seem to discuss this issue at all. Or is a MPLS label path
> >> automatically reversible?
> >>
> >> It would be desirable if the MPLS people could consider if
> >> there exist
> >> other ways of providing for the standard assumption on link
> >> layers that
> >> header compression has? For these assumption please see
> >> chapter 2 of RFC
> >> 2508, section 4.1 of RFC 3095, and RFC 3409.
> >>
> >> For example, what would be the effects of requiring unique labels
> >> between ingress and egress and for the reverse path?
> >>
> >> What effects would it have to put the multiplexing point 
> in the layer
> >> two extension?
> >>
> >> I would also like to see the draft be more header compression
> >> agnostic
> >> as has been agreed on in the requirements phase. There is 
> no problem
> >> with using ECRTP as an example how one realize the solution,
> >> however the
> >> necessary hooks and signalling must be in place for any header
> >> compression mechanism.
> >>
> >> So lets get the discussion going and hope that something 
> good results.
> >>
> >> Cheers
> >>
> >> Magnus Westerlund
> >> AVT Chair
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
> >
> 
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls