Requirements for Header Compression over MPLS
draft-ietf-avt-hc-mpls-reqs-03

[Ballot comment]
!! Contains embedded space:
  P005 L044:    document are to be interpreted as described in [RFC 2119].
!! Missing citation for Normative reference:
  P008 L049:    [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement

o: azinin@psg.com
Subject:  draft-ietf-avt-hc-mpls-reqs -  Remove Discuss?
Cc: loa@pi.se, magnus.westerlund@ericsson.com, csp@csperkins.com, mankin@psg.com
Fcc: +outbox, +Track
Reply-To: mankin@psg.com
--------
Alex,

I should have spoken too, but the Discuss was yours here, and
had been handled...this has been a very delayed response.

I believe that the AVT document on requirements for MPLS
header compression for AVT is clear under the analysis which was
summarized by the AVT shepherd and the Editor below.

Speaking to a well-taken point of Loa's, I've entered one
change as an RFC Editor Note, which I think is necessary:

OLD:
  These MPLS
  signaling protocol extensions need coordination with other working
  groups (e.g., MPLS).
NEW: 
  The specific MPLS signaling protocol extensions to support these
  approved requirements need to be developed as a well-coordinated
  separate document in the MPLS working group.
  The IETF needs to support a coordinated process for the two solution
  documents, though they are in separate areas.

Allison

P.S. I propose to interpret the last sentence as having TSV administering
one Last Call for the two solution documents - to save peoples' sanity. 
MPLS owns the extensions but not the decisions about the
application that uses the extensions.

------- Forwarded Message

Date:    Wed, 27 Oct 2004 12:43:36 -0500
From:    "Ash, Gerald R \(Jerry\), ALABS"
To:      "Magnus Westerlund" ,
        "Allison Mankin" , "Alex Zinin"
cc:      "Ash, Gerald R \(Jerry\), ALABS" ,
        "Colin Perkins"
Subject: RE: Progressing draft-ietf-avt-hc-mpls-reqs-03.txt

---------
Magnus,

> The review by the MPLS WG went out some weeks ago, and what I can see
in
> the MPLS WG archive only one technical comment was raised.
>
> That comments indicate that the draft do lack one requirement in
regards
> to MPLS. A MPLS HC solution needs to handle cases where the LSP label
is
> changed during the transition between the ingress and egress of the
MPLS
> network. The requirement would need to be suitable reworded to use the

> correct language, and would also need a paragraph or two of
explanation.

I did not think there were any outstanding unresolved issues raised.  I
think you are referring to this exchange with Thomas Eriksson concerning
penultimate hop popping (PHP):

http://cell.onecall.net/mhonarc/mpls/2004-Sep/msg00037.html
http://cell.onecall.net/mhonarc/mpls/2004-Sep/msg00038.html

My reply indicates that there is no additional issue or requirement.
Loa Andersson agreed in his email summary (attached):

"2. The comments from Thomas below, I've no problems with
    most Jerry's responses. He is right about the PHP, the LSP
    goes all the way to the egress although no label is
    carried with the packet."

Given that, I don't believe any additional requirements or explanatory
text needs to be added.  I'm not aware that any other issue was raised
that is unresolved.

> Do Alex and Allison agree that such a change is needed and
advantageous
> and that a updated draft needs to be submitted?

I'll be interested of course to see if Alex and/or Allison have a
different opinion about the need to add requirements/text.

> Jerry, can you propose such language? If the ADs sign off on the
change,
> please do also correct the boilerplate and ensure that it runs error

> until the ADs has given explicit approval.

Let's wait until we hear from Alex and Allison regarding any needed
additional text or requirements.  I'll be pleased, of course, to correct
any ID-nits, boilerplate, etc., in any case.

Thanks,
Jerry


- ------
Subject: mpls wg review of draft-ietf-avt-hc-mpls-reqs-03.txt] - response
Date: Wed, 29 Sep 2004 03:01:53 -0500
From: "Loa Andersson"
To: "Allison Mankin" ,
        "Alex Zinin" ,
        "George Swallow"
Cc: "Thomas Eriksson" ,
        "Ash, Gerald R \(Jerry\), ALABS"

Allison and Alex,

we got two responses from the mpls working group.

1. my own on the ecmp in a private mail tht you have
    seen - I'm not the person to evaluate the response
    but would suggest that it should be further discussed
    among hc-people.
2. The comments from Thomas below, I've no problems with
    most Jerrys responses. He is right about the PHP, the LSP
    goes all the way to the egress although no label is
    carried with the packet.
    I'm a bit concerned by the practice to point to the
    proposed solution to explain requirements, this should
    be self-contained in the requirments. Possibly the need
    for the session context id (SCID) also need to be better
    spelled out in the requirements draft

A further comment (mpls wg co-chair hat on). Given that the
mpls wg is the owner of rsvp-te (which the same as rsvp),
changes to that protocol needs to be brought to the mpls
wg in the form internet draft. This is analog to the split
of work between the mpls/ccamp/l3vpn/l2vpn on one hand and
changes to that protocol needs to be brought to the mpls
wg in the form internet draft. This is analog to the split
of work between the mpls/ccamp/l3vpn/l2vpn on one hand and
idr on the other. Since the draft-ash-avt-ecrtp-over-mpls-
protocol-01.txt is not a avt wg doc the authors should be
asked to split it in one avt draft and one mpls draft.

/Loa

The review of this by the MPLS WG was then followed by inaction by the Discussing
AD (lack of pinging admitted ).  Review summary is entered in log next.

Meanwhile, the AVT WG developed consensus to work on the protocol
document (reflecting this in a charter to be presented to IESG 12 May 2005).
MPLS elements will be in a specification in the MPLS WG, with early discussion of
the AVT side document.  I will propose TSV shepherd both for coherency.

[Ballot comment]
Reviewed by Scott Brim, Gen-ART

His review:

This draft is fine.  Please progress it.  (It took a few phone calls to
understand the context and come to that understanding.)

It could use a tiny bit of boilerplate tweaking, as do all:

  idnits 1.36 (12 Sep 2004)

  draft-ietf-avt-hc-mpls-reqs-03.txt:

    The document seems to lack an Abstract section
    Checking conformance with RFC 3667/3668 boilerplate...
    The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure Acknowledgement
    -- however, there's a paragraph with a matching beginning. Boilerplate error?
    There are 3 instances of too long lines in the document,
    -- the longest one being 1 character in excess of 72.