Subject: [NSIS] Meeting Minutes

From: [email-masked]
Date: Mon, 14 Apr 2003 10:20:18 +0300

Hi all,

Here are the meeting minutes.  Thankes to Hannes & Sven for taking minutes.

John

NSIS Meeting (Day 1)
++++++++++++++++

Minute Taker: Hannes Tschofenig

Agenda Bashing
-----------------------

Done by John.

Interim Meeting Review
---------------------------------

John gave the summary of the interim meeting with a list of consensus and problematic issues. His presentation can be found at: 
http://www-nrc.nokia.com/sua/nsis/ietf56/nsis-agenda.ppt

John will send these issues to the NSIS mailing list. NSIS members might want to comment them. 

RSVP Discussion (Melinda)
----------------------------------------
Melinda went through her presentation. 

Q: Is fragmentation not done in a hop-by-hop fashion?
A: End-to-end addressing prevents this.

Problems to solve (Henning)
-----------------------------------------

Henning went through his presentation. 

Conclusion: 

- Don't create a custom transport protocol with the ntlp/nslp work
- Allow raw ip + other transport protocol
- Allow separation between discovery and signaling message delivery

MT: The problems of raw transport are not as difficult. We should keep the ability of support for unreliable transport. 

Henning: This is what I said. We should not exclude some transport protocol. 

Both agree that different transport protocols should be supported. 

Melinda: We should not discuss the security issues. We want to modify RSVP as the charter says it. What do we really need to do? 

Henning: What does it mean to modify RSVP? Modified protocol X can mean
a) Keep the protocol backwards capability
b) No backwards capability. You have a different protocol then. Does not preclude you from taking design features of the original protocol.

John: Initially we wanted to separate different services
Should we separate discovery from message delivery?

Henning: I assume RFC 2961 when we talk about RSVP. 

Melinda: The end-to-end behavior is important. Routing is the important issue.

Lixia: Could you summarize your talk? 

Henning: A flexible NSIS protocol is required. 

Lixia: Have you identified the negative sides?

Henning: If a reliable transport is needed then there might be additional delay for setup a TCP connection (only once if it is reused by multiple NSLP sessions).

Bob: Melinda mentioned the problem of signaling cases which are so trivial that you cannot amortize. 
What would you suggest for DNS?

Henning: Most of the time signaling fits fine into the architecture. However, you might want to provide a fall-back mechanism. I am not trying to motivate NSIS with a DNS example. 
If you don't need it then you don't need to use it. 

Bob: If we don't want to support transport protocol (a), (b) or (c). You don't need to decide. The same is true for discovery. Can this group design a protocol with such a flexibility?

Lixia: Look at the most important protocols. They are successful because they are simple. 

Henning: Separation makes protocols even simpler.

Q: What are the assumptions?

Henning: 
- Signaling traffic should be protected
- It is unwise to assume that intra-domain signaling messages are protected. 

We cannot assume any characteristics of the network since we additionally cover other signaling application cases.

Melinda: You cannot assume that there are always NSIS capable routers along the path. 

Henning: This is another motivation for discovery. 

Q: Provisioning of flows can be done to avoid all the transport layer discussions. DiffServ marking for signaling traffic can be done. 

Henning: You cannot make this assumption. 

MT: You get a lot of problems if you support more than one transport protocol.

Henning: My motivation is more to prevent people from creating their own transport layer functionality at the NSLP.

MT: Allowing fragmentation support (with the ability to switch) sounds ok to me.

John: Summary:
- Agreement that we want to separate the service part. 
- We want to modify RSVP. 
- Off-line discussion with Melinda, Henning and ADs about further procedure.

RSVP Analysis (Jukka)
-----------------------------------

Idea: Capture knowledge about RSVP. 
Remove ITSUMO (more architecture work). 
Revised sections

Proposal to move forward: 
- Add Michael Thomas draft
- Add Ping Pan text 

John: 
- We have to work on issues where RSVP cannot be used/modified for our purpose. 
- This work is needed to explain which changes are required. 
- Avoid stories about RSVP which are not justified (e.g. "RSVP does not scale" ) . 
- More reasonable to combine documents than to have many separate RFCs. 
- Jukka should talk to Michael about co-operation. 

RSVP Transport Issues (Ping)
--------------------------------------------

Ping went through his presentation. 

Ping: This is not RSVP-bashing. It is about observation. 

Summary: 
- Timer handling is complex (a single TCP connection between two routers would be a lot easier)
- Large number of messages is a problem (message packing). Causes MTU issues. 
- Nothing should affect RSVP-TE but RSVP-TE is not in scope of NSIS work anyway.

Proposed Changes:

- No need for IP Router Alert Option for PATH
- Flexible message transport

Lixia: Timer handling might be similar to TCP. RSVP and TCP data delivery are different.
Harmful: Heavy load BGP traffic (later message overwrites previous one)

Ping: This is a problem for the NSLP not for the NTLP. RSVP maintains timers for individual sessions.

	Lixia: The solution to the problem is different. 

MT: Security objects are not a problem for MTU. 

Hannes: Proposals available today already cause problems (e.g. Identity Representation objects). 

NSIS Meeting (Day 2)
++++++++++++++++

Agenda Bashing (John)
-------------------------------

Meeting in the morning and discussion with area directors. The conclusion of this discussion can be obtained from: http://www-nrc.nokia.com/sua/nsis/ietf56/nsis-agenda.ppt

Summary: The proposal is that Henning and Melinda would start NTLP work. Bob and Michael will act as expert reviewers. 

Marcus: Some other authors should participate. 

John: Bring it to the mailing list. 

Q: Flow Id is used by some other WGs. 

John: We will make sure to refer to it as the to Flow Spec. 

Q: Flow Label draft needs to be revised. Please comment on it to the IPv6 mailing list.

John: Review the draft and raise your concerns with the requirements document.

NSIS Requirements (Marcus)
---------------------------------------

Most of the issues have been discussed at the interim meeting. 
  Remove QoS-specific issues
  Terminology alignment with framework

Framework Presentation (Robert)
------------------------------------------------

Robert goes through his presentation.

Robert: Some issues need to be discussed case-by-case. Favorite example is bundling (reliability is more complex) which is a local issue only.
Melinda: What are local issues?
Robert: Message Bundling effects only two peers. 

Issue 3: Mobility

Mobility handling has not yet been captured yet. 
Impacts what type of optimizations can be achieved. 
More discussions are needed. 

Issue 4: One or many hops

Refers to whether NTLPs are always co-located with NSLPs. 

Issue 5: State management

Mike: Why is it not an implementation issues?

Robert: Example is cost: accumulation of cost.
  Requirements may be different for different NSLPs.
  Impact may be: distinguish between refresh and non-refresh at NTLP

Next Steps (John)
  Come to agreement on issues.

  Next version available in May

  Charter says submission to IESG in July

  Schedule NTLP first version before next IETF

RSVP security properties (Hannes)
------------------------
Added sections to cover: first hop, last hop.

Removed section about AAA - covered in separate document.

Next hop: editorial clean up and shortening, add references, comments welcomed

[JL] The working group should read the document and make comments.

NSIS threats (Hannes)
------------
Introduction rewritten
  * relationship to other security issues
  * more detailed threat description
  * new threats
  * deployment issues (missing authorization, cost control)

[JL] The WG will do thorough read and maybe go the WG last call soon.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Xiaoning He" <[email-masked]>
Date: Wed, 16 Apr 2003 11:46:40 -0700

Hi all

I have a simple question regard RSVP. Could anyone give me some
information about this?

How many RSVP flows a state-of-art router can handle per second
currently? 

Thank you very much,

Xiaoning

-----------------------------
 
Xiaoning He, Ph.D
Research Engineer
 
NTT-DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
 
Email: [email-masked]
Phone: +1 (408) 451-4737
Fax:   +1 (408) 573-1090