Subject: [Speermint] Comments on draft-ietf-speermint-requirements-04

From: "Elwell, John" <[email-masked]>
Date: Mon, 03 Mar 2008 08:03:41 +0000

Jean-Francois,

1. "SPP" - this is used several times, but not defined. The expressions
"session peering point" and "session peering policy" are used in various
places in the document - which does it mean? The phrase "parameters that
SPPs may consider" suggests neither of these expansions fits - it
suggests something like an administration.

2. "Session peering point" - this sounds like a new term, not defined in
the Terminology draft. I notice the Architecture draft uses "peeing
point", but that too is not defined in the Terminology draft. If we need
such a term, it should be common to the various documents, but given
that it seems to mean either signalling path border element or data path
border element, wouldn't "border element" be more appropriate?

3. "maximum flexibility should be given for how signaling path and media
   path border elements are declared, dynamically advertised and
   updated"
Why is updating of these elements relevant (software update,
presumably)? Should it instead refer to the updating of advertisements?

4. "media
   path border elements"
There is a defined term "data path border element" - use that.

5. "Note that this may not be
      applicable to all types of session peering (voice may be a
      particular case where this is needed -- at least based on current
      practices)."
This note refers to the advertisement of egress SBEs, so why does the
type of media (e.g., audio) influence the choice of egress SBE? In fact
the media used will not be clear until the SDP answer, and also it may
change during the course of a call. The choice of SBE should be
independent of media.

6. "a mechanism
   should exist to allow SSPs to advertise their media border elements
   responsible for egress and ingress data path border elements (DBEs)"
Why introduce the term "media border elements"? Why not just talk about
advertising egress and ingress data path border elements, rather than
advertising some entity that has responsibility for them?

7. "While some SPPs may have open policies and accept
   media traffic from anywhere outside their network to anywhere inside
   their network, some SSPs may want to optimize media delivery and
   identify media paths between peers prior to traffic being sent (layer
   5 to layer 3 QoS mapping)."
I think I have questioned this before - I still find it hard to
understand. DBE addresses are exchanged in SDP, i.e., before any media
is delivered. That is normal SIP. Unless there is a requirement for a
SSP to influence the choice of DBE used by a peer SSP (which SIP cannot
do), then I don't see any need for a requirement here. If there is
indeed a need to influence a peer SSP in this way, the present wording
of the requirement doesn't make this clear.

8. "Requirement #4".
All the motivation behind this requirement is very weak and seems to
encourage policies that deny the ability of SIP to vary a session
without re-establishing a call, e.g., establish as audio, later add
video, later add MSRP, later add collaboration, and so on. Or
conversely, establish with all of these and fall back to just one or
two. The SBE in general will be chosen without any knowledge of which
media will be present during the call.
Obviously there are some things that do indeed require special
signalling, e.g., SIP MESSAGE requests and SIP subscriptions and
notifications relating to presence etc. Is the motivation for
requirement #4 more geared towards these (i.e., different SIP methods,
different URI schemes)? If so, it is perhaps better not expressed as
different media.

9. "It should be possible for an SSP to define which egress SBE a SIP
   entity must use based on a given peer destination."
I would say this is an internal matter for the SSP, and does not involve
any peer SSP. Therefore it is probably outside the scope of SPEERMINT.

10. "3.4.  Other Considerations

   The considerations listed below were gathered early on in the
   SPEERMINT working group as part of discussions to define the scope of
   the working group.  They have not been updated in this revision of
   the draft."
What will be the future of this section? Will it be removed, or do we
need to do work to derive concrete requirements, or will it be moved to
an appendix?

11. "We then describe
   security considerations for the three types of information flows
   described in the use cases: the data queried from the Lookup or
   Location Routing Functions, data exchanged in the SIP signaling
   between SSPs (directly and indirectly), and media."
There are also several requirements that talk about advertising or
communicating information between SSPs - should this be discussed from
the security point of view?

12. "5.3 Hop-by-hop Security for SIP Signaling and TLS Considerations"
This is quite a long section that does not generate any requirements.
Should it do so (e.g., relating to agreement of certificates or CAs to
be used? Otherwise, why do we need the section?

John
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Tue, 11 Mar 2008 09:54:20 -0400

John:
I actually interpreted Requirement #4 as speaking to something
different, that is the ability to specify different peering points for
different peering partners. On that basis I'd prefer to keep it.

Penn Pfautz
AT&T National Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Monday, March 03, 2008 3:04 AM
To: [email-masked]; Jean-Francois Mule
Subject: [Speermint] Comments on draft-ietf-speermint-requirements-04

8. "Requirement #4".

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 12 Mar 2008 12:09:27 +0000

Penn,

I still don't see how, from the INVITE request, you can predict all
media that will be used throughout the call. For example, it could start
with audio, then add video, MSRP, file transfer, etc. later.

John 

> From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]] 
> Sent: 11 March 2008 13:54
> To: Elwell, John; [email-masked]; Jean-Francois Mule
> Subject: RE: [Speermint] Comments on 
> draft-ietf-speermint-requirements-04
> 
> 
>  John:

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 12 Mar 2008 06:23:29 -0600

John,

   Thank you for continuing to review the document and for providing feedback. See inline.  

   I have updated the draft based on the reply below and plan to post an I-D update addressing your comments and others just after the IETF.

Please review and let me know.
Jean-François

> From: Elwell, John [mailto:[email-masked]]
> Sent: Monday, March 03, 2008 1:04 AM
> Subject: Comments on draft-ietf-speermint-requirements-04
> 
> Jean-Francois,
> 

Ok, my bad, SPP is in fact SSP (SIP Service Provider).
Fixed 3 occurrences:
ietf/speermint/draft-ietf-speermint-requirements-04.txt:261:
 The informative Appendix A lists parameters that SPPs may consider
/ietf/speermint/draft-ietf-speermint-requirements-04.txt:324:     
  if applicable.  While some SPPs may have open policies and accept
/ietf/speermint/draft-ietf-speermint-requirements-04.txt:534:        
  of parameters and other information needed by an SPP to connect to

> point", but that too is not defined in the Terminology draft. If we

I don't think we need to define what a peeing point is in the terminology draft, or even session peering point to focus on the subject at stake.

> need
Yes, s/session peering point/border element
Fixed 3 occurrences:
/ietf/speermint/draft-ietf-speermint-requirements-04.txt:75:
  3.2.  Session Peering Points 
/ietf/speermint/draft-ietf-speermint-requirements-04.txt:267:
  3.2.  Session Peering Points
/ietf/speermint/draft-ietf-speermint-requirements-04.txt:290:
     session peering points between SIP Service Providers; they include

> presumably)? Should it instead refer to the updating of
This is indeed a confusing statement. It should refer to the updating of advertisements but this point is not carried forward in the following paragraphs.
So the new text says:
"For border elements to be operationally manageable, maximum flexibility should be given for how border elements are declared or dynamically advertised."

> There is a defined term "data path border element" - use that.
Ok, fixed.

> This note refers to the advertisement of egress SBEs, 
It is a note inside a paragraph explaining the motivations of requirement #2:
"      Protocol mechanisms should exist for a SIP Service Provider (SSP)
      to communicate the egress SBEs of its service domain."

> so why does the
> type of media (e.g., audio) influence the choice of egress SBE? In
This is not implied here.  The full text before the note states:
"      For the purposes of capacity planning, traffic engineering and
      call admission control, a SIP Service Provider may be asked where
      it will generate SIP calls from."
And this note basically says that capacity planning may be more of a considerations for VoIP peering than IMs.  I can remove this note if you think it is misleading - please review and let me know.

> fact
> change during the course of a call. 
> The choice of SBE should be independent of media.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It might in some networks, it might not in others.  IMs may leave my enterprise network from different servers (SBEs) than my voice calls because they may be subject to different policies.  No changes were made in the draft.

> advertising some entity that has responsibility for them?
Agreed, fixed terminology.
New text states: "a mechanism should exist to allow SSPs to advertise their  egress and ingress data path border elements (DBEs), if applicable."

> understand. 
Ok, note that we both discussed it in Vancouver.  I added text to indicate that some SSPs do this today, others do not based on our discussion.

> DBE addresses are exchanged in SDP, i.e., before any media
> is delivered. That is normal SIP.
And this is of course unchanged.

> Unless there is a requirement for a
> do), then I don't see any need for a requirement here.
This is not the point.  
The requirement is that some SSPs requests that a peer provides to provide the list of DBEs or IP sub-nets where data traffic can originate from.  Folks build ACLs, or static mapping of layer-3 QoS mappings based on IP-subnets and ports (not scalable, not terribly secure but this is what's being done in networks today). I think this is a valid case also seen today in enterprise-to-enterprise communications, enterprise to SIP provider (SIP trunk) and even SSP to SSP.
The most convincing argument I heard is capacity planning: some SSPs want to know where media will come from based on their IP backbone interconnects at L3-peering to do proper capacity planning and even adjust or police diffserv marking policies for media.

I will raise this as an open issue again at the meeting.  Further comments on the list are appreciated too.

> If there is
This is less about influencing a peer than it is to ask the peer how/where its media will flow out, and instead of exchanging Excel spreadsheets called site surveys, and email, have means to advertize and adjust this dynamically.  This data is for example used by some SSPs to do Diffserv policing of media traffic coming in.

> 8. "Requirement #4".
To Penn Pfautz's point, this is about being able to specify different border elements for different peering partners or media types.

> encourage policies that deny the ability of SIP to vary a session
I would note that the requirement is to have a mechanism to be able to do this.  The document does not encourage the use of such mechanism.

> video, later add MSRP, later add collaboration, and so on. Or
In those cases, you do not want to use this mechanism indeed.

> different URI schemes)? 
Yes.

> If so, it is perhaps better not expressed
> as different media.
Can you propose some edits that capture this point to your satisfaction?

> any peer SSP. Therefore it is probably outside the scope of
Take this example:
2 SSPs agree to do L5 peering in multiple locations, including NYC and Paris. SSPa does not want to carry the cost of transporting media from Paris to NYC for SSPb and requires that calls from subscribers of SSPb originated in Paris to subscribers of SSPa in NYC be carried on SSPb's network all the way to NYC and then be egressed in NYC to SSPa. SSPa requires a list of SBEs from SSPb at the various POPs to restrict CAC based on originating or egress SBE.
Does this example help justify the requirement?

I have raised this as an open issue for discussion at IETF#71.  Other opinions on this?  

> need to do work to derive concrete requirements, or will it be
The wg has pretty much agreed that all of these considerations should not lead to requirements.  Some paragraphs still help understand the approach.
I would suggest the following:
 - remove these 2 paragraphs:
   o  It is assumed that session peering is independent of lower layers.
      The mechanisms used to establish session peering should
      accommodate diverse supporting lower layers.  It should not matter
      whether lower layers rely on the public Internet or are
      implemented by private L3 connectivity, using firewalls or L2/L3
      Virtual Private Networks (VPNs), IPSec tunnels or Transport Layer
      Security (TLS) connections [RFC3546]...

   o  Session Peering Policies and Extensibility:
      Mechanisms developed for session peering should be flexible and
      extensible to cover existing and future session peering models.
      It is also recommended that SSP policies be published via local
      configuration choices in a distributed system like DNS rather than
      in a centralized system like a 'peering registry'.
      In the context of session peering, a policy is defined as the set
      of parameters and other information needed by an SPP to connect to
      another.  Some of the session policy parameters may be statically
      exchanged and set throughout the lifetime of the peering
      relationship.  Others parameters may be discovered and updated
      dynamically using by some explicit protocol mechanisms.  These
      dynamic parameters may also relate to an SSP's session-dependent
      or session independent policies as defined in
      [I-D.ietf-sipping-session-policy].

- Move this into appendix A with some editing to integrate the text:
Administrative and Technical Policies:
      Various types of policy information may need to be discovered or
      exchanged in order to establish session peering.  At a minimum, a
      policy should specify information related to session establishment
      data in order to avoid session establishment failures.  A policy
      may also include information related to QoS, billing and
      accounting, layer-3 related interconnect requirements which are
      out of the scope of this document, see examples in Section
      Appendix A.

Comments welcome.

> the security point of view?
Can you elaborate and propose text?

> be used? Otherwise, why do we need the section?

I got conflicting requests here.
One the one hand, SIP security is out of scope so we can't have formal requirements on this (and there are no new requirements on SIP mechanisms for session peering imo). On the other hand, this has been in the document since after the interim meeting in 2005 and folks wanted more details that just say "use TLS".
In draft-04, I started to cut some of the text (see Diff on ietf's tool page) based on the information now captured in other drafts.   I'm still inclined to leave this informative text so that folks (implementers/SSPs) do this more about what they need to enable from a configuration/policy standpoint when discussing security questions.

Is that ok or should there be more edits to articulate the intent of this section?
If you see specific requirements that can be derived, please share.

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Wed, 12 Mar 2008 09:04:58 -0400

John:
I don't disagree with that point but I believe that part of the
motivation for the requirement was to allow an SSP to specify different
interconnect point for *different SSPs* as opposed to different media
types. It's the former type of differentiated peering that I want to see
preserved.

Penn Pfautz

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2008 8:09 AM
To: PFAUTZ, PENN L, ATTCORP; [email-masked]; Jean-Francois Mule
Subject: RE: [Speermint] Comments on

Penn,

John

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 12 Mar 2008 07:23:22 -0600

> with audio, then add video, MSRP, file transfer, etc. later.

This is where we have a disconnect.
Let's clarify the requirement to clear these confusions.
 
I assumed that this variability comes into play during the look-up and
location resolutions (so called LUF/LRF nowadays). The motivation behind
this requirement is to be able to say: for voip, here are my SBEs, for
IMs/presence, here are my IM/presence servers.

The response to a look-up may vary based on the peer (based on who ask,
you may want to have different SBE), and based on what "media" or
service type is requested:
	- enum query on a tel potentially returns NAPTRs that will
result in pointers to voice SBEs
	- sip query on im URI returns a 302 redirect that will
ultimately point to IM SBEs

If there is agreement that there should be a means to express different
SBE based on the media/service type, how do we formulate this more
clearly?
If we don't have agreement that this is important, now is the time to
say: "this is stupid", any SBE will handle every type of SIP/IM query
and no one will ever need to provide different SBEs based on the type of
media/traffic.

Jean-Francois.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Mar 2008 11:23:02 +0000

Jean-Francois,

See below.

John 

> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: 12 March 2008 13:23
> To: Elwell, John; PFAUTZ, PENN L, ATTCORP; [email-masked]
[JRE] Yes, you can certainly do this. However, bear in mind that if you
select a voice SBE and then, during the course of the call, IM is added
to the call, the voice SBE will still continue to handle the call. So
the exercise of trying to assign traffic to particular SBEs according to
media seems to be ineffective.

I don't object strongly if you want to keep this, provided the
limitations are stated.

Allocating requests to different SBEs according to SIP method (e.g.,
INVITE, MESSAGE, SUBSCRIBE) might have more value.