Next Steps in Signaling WG (nsis)

Tuesday, March 8 at 1645-1745
Thursday, March 10 at 1300-1500
===============================

CHAIR: John Loughney <john.loughney@nokia.com>

Minute Taker:
- Kwok Ho Chan

Minutes compiled by Hannes Tschofenig

Jabber Scribe:
- Andrew McDonald
Log Day 1: http://www.xmpp.org/ietf-logs/nsis@ietf.xmpp.org/2005-03-08.html
Log Day 2: http://www.xmpp.org/ietf-logs/nsis@ietf.xmpp.org/2005-03-10.html

Unofficial Weblog: http://www.ietf-nsis.org

Abbreviations:

- John (John Loughney)
- Robert (Robert Hancock)
- Hannes (Hannes Tschofenig)
- Martin (Martin Stiemerling)
- Pete (Pete McCann)
- Sung (Sung-Hyuck Lee)
- Attila (Attila Bader)

AGENDA:

Agenda Bashing
WG Update
John Loughney - 10 min

http://www.ietf-nsis.org/nsis/IETF62/nsis-ietf62.ppt

GIMPS
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-05.txt
Robert Hancock - 20 minutes

http://www.ietf-nsis.org/nsis/IETF62/draft-ietf-nsis-ntlp-05.ppt

Three major issues still open:
-----------------------------
1. Protocol Extensibility (using Extensibility in NSIS slide)
John on the mike asking for some guidance from AD and Bob Braden
concerning how extensible RSVP is and what was learned from RSVP
on this regard, trying to have NSIS not make the same mistakes.
Bob:
Have the issue of objects being shared between NTLP and NSLP,
this may be a problem. Also, adding more guidance in the
extension section and more text in the IANA consideration section.
Allison:
A good example may be in DCCP draft (just finished and approved as RFC).
John:
May be adding another new draft on the charter to cover this.
Bob indicated that it may be good to put this into the Framework RFC
(use a new RFC to replace the current NSIS Framework RFC).
Cedric:
There may need a flag indicating that a capability must be supported
by all NSIS nodes or the capability should not be indicated as
working/supported. (This is available in BGP).
Robert: Don't really agree on adding this new flag.
John: Add something in the IANA section and send them to Robert.

2. Adding Routing State Setup
3. Design Finalisation
NAT stuff will be covered by Cedric.

=======================================================
Loose End Message Routing Method for NATFW NSLP (LEMRM)

http://www.ietf.org/internet-drafts/draft-stiemerling-nsis-natfw-mrm-01.txt
Martin - 20 mins

http://www.ietf-nsis.org/nsis/IETF62/IETF62-NSIS-NATFW-MRM.ppt

Cedric:
Have some question on the form of the MRM.
There needs to be some kind of filter be define in MRM.
Martin:
The RouterOption should be used in the original message, hence
a special filter may not be needed.
Cedric:
May be some port numbers can be used in the special filter.
Robert:
Thinks that this can be done, don't think this is that hard technically.

============================================================

GIMPS state machine
http://www.ietf.org/internet-drafts/draft-fu-nsis-ntlp-statemachine-01.txt
Cedric Aoun - 10 min

http://www.ietf-nsis.org/nsis/IETF62/IETF-62-GIMPSFSM-02.ppt

Most of the work mainly done by students Cedric, Xiaoming and Hannes works with.

- Two modeling paradigms:
-- Signaling initiator, intermediary and responder
--- works but appears to be unnecesaarily complex.
-- Query node and responder node
--- next version will document use of this second paradigm.

Open issues:
- Lost Confirm message (elaborated in draft-ietf-nsis-ntlp-05.txt)
- Separate FSM for the MA might be useful
- two other open issues on Cedric's slides.

Next Steps:
- simplify the overall state machine

- Want to check out the simplified state machine using the
four initial implementations
-- Roke Manor/Siemen
-- NEC
-- Cedric/Student
-- Elywn

- Do we want to have a separate state machine document or
integrate this into the NTLP document?
John: Lets discuss this off-line.
Bob Braden: Depending on the objective, may not want to put
all the implementation details into the NTLP doc.

=============================================

NSIS Mobility Applicability
http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-01.txt
Sung-Hyuck Lee - 10 min
Slides published.

http://www.ietf-nsis.org/nsis/IETF62/nsis_mobility_Mar-8-2005.pdf

Main issue #4
There was some discussions on leave it to the NSLP state timeout to handle
the state tear down. This may not allow the Mobility NSLP to scale,
especially when there are many handovers.

Next Steps: See slides.

UpToHere on Tuesday
====================================================

Metering NSLP
http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-00.txt
http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-01.txt
Juergen Quittek - 10 min

http://www.ietf-nsis.org/nsis/IETF62/nsis-m-nslp-ietf-62.ppt

Discuss this on Thur, presented by Juergen.
Path coupled signaling on measurement.

This work is also interested by other WG (IPFIX) that may be discussed
in Paris. Couple of people are interested on doing this in NSIS.

Next Step:
Continue working on this as individual draft.

=====================================================

THURSDAY, March 10, 2005
1300-1500 Afternoon Sessions I

NAT-FW NSLP
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-05.txt
Martin (tentative, might be Hannes or Cedric) - 20 mins
Martin presenting

http://www.ietf-nsis.org/nsis/IETF62/IETF62-NATFWNSLP-04.ppt

Hannes on the mike:
With this document we made another step to complete the work.

We have discussed security threats for some time and described them in a separate threats document.

A few selected issues have been discussed on the mailing list over the last few months (related to the 'receiver behind the nat' case).

Now, the security threats and the security requirements being completed we have intergrated the threats document into the main document.

The solution section has been updated but not yet finalized.

Discussions with regard to mobility and security are still necessary and will be done together with the nsis mobility folks.

==============================================

3GPP2 FW Signaling Requirements
http://www.ietf.org/internet-drafts/draft-bajko-nsis-fw-reqs-00.txt
Franck Le - 10 min
draft-bajko-nsis-FW-reqs-00.txt

http://www.ietf-nsis.org/nsis/IETF62/3GPP2FWSignalingRequirements-FranckLe.ppt

These requirements are from the 3GPP2 prospective.
A liason have been sent from 3GPP2 to IETF.

Pinhole Creation Requirements
Pinhole Deletion Requirements
Packet filters Req
State Update Req
Transport Protocol Preferences

Going over the Firewall Features Req:

John indicated that these are requirements from another standards org,
need to check with the ADs on how to handle this.

Hannes: The document is very interesting input for us.

Some of the requirements are already fulfilled with the most recent draft version.

Some others can be addressed and again some others need further discussion.

Martin: about 80% of these requirements are already being handled.

Cedric: indicating that some of these are dynamic FW configs, some are static
FW configs. And some of these may be handled by another WGs. Hence this
may not be handled in NSIS, neeeds to identify each catorgory on the list, off line.

Bob Braden: Some of the req uses "should" and "must" in a funny way, may need
to understand how "should" and "must" means/used in this context.

==============================================
NSLP QoS
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-06.txt
Andrew McDonald - 20 min

http://www.ietf-nsis.org/nsis/IETF62/qos-nslp-ietf62.ppt

==============================================
QoS-NSLP QSPEC Template
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-03.txt
Jerry Ash - 10 min

http://www.ietf-nsis.org/nsis/IETF62/ietf62-nsis-qspec.ppt

Dave Oran: Posting issues with routing changes, etc.
Indicating that the QSpec needs to be attached to an OI.

David Black:
In the RMD draft, there are mixes of using IntServ parameters applying to
DiffServ services, this is wrong and can be dangerous.
The same may happen here, this doc provides a flat space, allowing
easy mistakes to be made. Suggesting to make this space hierarchical, i.e.
DiffServ/IntServ then the parameters that can be used for each.

Bob Braden: disagree with what David Black says, that many of the parameters
are generally applicable to different kinds of resource management.

There is a discussion between David Black, Dave Oran, and Bob Braden on
how best to shape the data model.

Georgios indicated some suggestions on usage of some boundary identification
when different types of QoSM is used. He was not clear on the mike.
Some of this may be discussed offline.

==============================================
Y.1541 QoS Model (QOSM)
http://www.ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt
Jerry Ash - 10 min

http://www.ietf-nsis.org/nsis/IETF62/ietf62-nsis-ash-y1541-qsp.ppt

QoS model based on ITU-T recommendation Y.1541.

Jerry: Next steps: Asking to make this a WG doc.

Bob Braden: this was good example of showing extensibility of QoS-NSLP/QSPEC

John: Who read the draft and who would support it as a WG item?

(About 10-15 hands up for each.)

Would like to discuss on the list and confirm interest in the WG before making this a WG doc.

==============================================
RMD-QOSM - The Resource Management in DiffServ QoS model
http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-01.txt
Attila Bader - 15 min

http://www.ietf-nsis.org/nsis/IETF62/draft-ietf-nsis-rmd-01.ppt

Discusses severe congestion handling.
Indicated max of 200 milliseconds for mobile handover

Discussed usage of congestion refresh messages.

David Black indicated re-use of 3168 instead of using new DSCP for
congested PHB.

Talk about usage of ECN probes.

Discussed some issues raised in TSVWG on
- additional DSCP to be used to separate traffic between using ECN
and not using ECN.

Showing PDR Nonce mechanism.

David Black's concerns with ECN:
1. Duplicating DSCPs for each PHB, i.e. 2 DSCP for each PHB (1 for ECN, 1 for none ECN).
2. ??

John asks Allison (as TSVWG WG chair and Transport AD)
about what is TSVWG going to do with RT-ECN?
Allison is suggesting to John that the Severe Congestion condition may be/
should be removed from the RMD and reuse the ECN mechanisms developed
by TSVWG.

Franciou of Cisco indicates that the Severe Congestion condition is the
hard problem to be solved, and it may not make sense to separate and
solve the easy problem so the draft is done, but leaving the harder
problem (severe congestion) to be solved in another draft or somewhere
else.

John: lets discuss this on the list and are welcoming the RT-ECN folks
to join in and discuss this in the NSIS list.

==============================================
Diameter Quality of Service Application
http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-02.txt
Hannes Tschofenig (tentatively, could also be Pete or Frank) -- 5 min
Pete presenting

http://www.ietf-nsis.org/nsis/IETF62/diameter-qos_ietf62.ppt

- address "three party token based" approach.
- discussed bearer gating functionality

Next steps
- extend the generic 3 party approach authorization
- extend authorization for QoS NSLP

Bob Braden:
Asks how is this related to COPS usage with RSVP.

==============================================

Some issues for NSIS signaling
http://www.ietf.org/internet-drafts/draft-sanda-nsis-path-type-02.txt
Takako Sanda

http://www.ietf-nsis.org/nsis/IETF62/nsis-path-type-ietf62_003.ppt

Issues: Multiple Paths Support.
Issues: Flow ID generation & addresses