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

["Jean-Francois Mule" <[e-mail]>]

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

> -----Original Message-----
> From: Elwell, John [mailto:[e-mail]]
> Sent: Monday, March 03, 2008 1:04 AM
> To: [e-mail]; Jean-Francois Mule
> Subject: Comments on draft-ietf-speermint-requirements-04
> 
> 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.

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


> 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

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
> 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?
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


> 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?
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."

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

> 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, 
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
> 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.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.


> 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?
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."


> 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. 
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
> 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.
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
> indeed a need to influence a peer SSP in this way, the present
> wording
> of the requirement doesn't make this clear.
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.


> All the motivation behind this requirement is very weak and seems
> to
> 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.

> without re-establishing a call, e.g., establish as audio, later add
> video, later add MSRP, later add collaboration, and so on. Or
In those cases, you do not want to use this mechanism indeed.

> 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)? 
Yes.

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


> 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.
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?  


> 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?
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.


> 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?
Can you elaborate and propose text?


> 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?

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.



> 
> John
_______________________________________________
Speermint mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/speermint