Subject: [Tsvwg] Comments on "MLPP-that-works" : DISA Requirements

From: [email-masked]
Date: Wed, 17 Aug 2005 10:04:38 EDT

Comments on draft-ietf-tsvwg-mlpp-that-works-02 (related to DISA/DOD 
requirements) while waiting for a Last Call to be announced:

The list of normative references needs to list the most recent version of the 
Assured Service Requirements, which was 
draft-pierce-tsvwg-assured-service-req-01. It recently expired, and I will resubmit it with minor changes when I 
figure out whether this should still be in TSVWG or would be more appropriate in 
the newly chartered IEPREP.

Various parts of the "MLPP-that-works" draft need to be coordinated with the 
stated requirements.

The title of the service is no longer "MLPP". That term should only be used 
in a historical sense. The referenced draft requirements stated:

"The term 'Assured Service' is used to refer to the required capabilities, 
rather than the previous term of 'MLPP' or the related but different terms of 
IEPS or ETS, since the envisioned set of capabilities and protocols to achieve 
them are not expected to be exactly the same as those other services."

Section 2 states that "call control is completely divorced from the data 
plane". While this may be true in some networks, the requirement in the referenced 
draft-pierce-assured-service-arch is that there be some connection between 
them in order to provide security and to control access to the capabilities of 
packet transfer preferential treatment.

Section 2.5 talks about the required announcements (for MLPP) and notes that 
"there is no known benefit to informing the user which Ethernet switch or 
router caused the call to fail". The requirements for Assured Service, as stated 
in the referenced draft, do not say this. These comments should be submitted 
against the documentation which addresses this issue.

Figure 2 shows "Reason: UA_preemption" being sent to UA Alice. In order to 
meet requirement Noti-2, the Reason "Generic_preemption" must be used.

Page 37 refers to the inclusion of a parameter which "will fail the call 
attempt" in case of an "RSVP failure". This is confusing. If RSVP indicates a 
failure to allocate resources, then the call will "fail" with or without this 
parameter. If there are other RSVP failures not related to unavailability of 
resources, it is not permitted to "fail the call", especially if a high precedence 
one, because of the failure of RSVP.

Page 43: The message back to Alice indicates the reason for the preemption as 
"RSVP_preemption". In order to satisfy the requirement, the 
"Generic_preemption" indication is required.

Mike Pierce
Artel
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg