Subject: [Tsvwg] Conflict between 2 TSVWG IDs need resolving...

From: "James M. Polk" <[email-masked]>
Date: Wed, 12 Sep 2007 14:37:33 -0500

All

(with my individual hat on)

There is a potential conflict between these two IDs:
http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-03
and
http://tools.ietf.org/wg/tsvwg/draft-polk-tsvwg-signaled-domain-id-00.txt

The emergency-rsvp ID is in WGLC, and I just presented the 
signaled-domain ID for the first time in Chicago, so it is an individual.

I am a co-author of both of these IDs, which makes this conflict a 
bit more interesting.

In the emergency-rsvp ID, the Application-Level Resource Priority 
(ALRP) policy element has a namespace field - which is equivalent to 
a numeric value of a SIP Resource-Priority (RFC4412) namespace.  This 
is because SIP is text based, and RSVP is binary, there needs to be a 
numeric value assigned to each SIP namespace when one is used in SIP 
for establishing a call that uses RSVP (and the ALRP policy element).

SIP namespaces are not domain specific, and can traverse any, and 
each, domain of an end-end signaling path.

The signaled-domain ID has a domain identifier field that is unique 
to each domain.  The draft currently actually has two such fields, 
one identifying the original domain the reservation started in, and 
the traversing domain of where the message is at the moment, for 
local nodes to make local decisions upon.  This allows SPs to only 
worry about their domain identifier when providing treatment to the 
reservation, yet allowing each traversing/traversed domain to 
understand which domain this reservation started from. [ I realize 
this ID is short on diagrams that could make its explanation easier 
to understand. The next rev will have these diagrams. ]

A secondary benefit to this, is how this domain id relates to the 
requirement for certain domains to have identifiable sub-domains.

There is a requirement to have SIP namespaces indicated in a RSVP 
element - with the ability to traverse each domain the SIP message 
does; the emergency-rsvp ID does this.  This makes this part of RSVP 
behave more at an application layer -- meaning this element is not 
bound tightly to a single domain, just as SIP is not.

There is a requirement to have a domain subdivided to provide 
sub-domain specific treatment of reservations. The latter requirement 
seems to necessitate a domain identifier be created so there is no 
leakage and unwanted affects on other networks.

Questions to the WG:

#1 - are these two sets of requirements unique enough to solve in 
separate documents?

	Possible solution - maintain each ID as separate, and progress

#2 - are these two sets of requirements (the ALRP namespace 
requirement and the domain ID requirement in signaled-domain) similar 
enough they should only be addressed in a single document?

	Possible solution - though less than optimal to #2:
             - a likely result of this would be to take the domain identifier
             out of the signaled-domain ID and rely on the ALRP element
             to be present (along with the existing requirement of the
             PREEMPTION_PRI element).  This will complicate a sub-domain
             identifier solution since the ALRP namespace is not tied to
            a single SP (ever).

#3 - keep the emergency-rsvp ID as is, but change the signaled-domain 
ID to not conflict the emergency-rsvp ID.

	Possible solution - make clear the distinction between the ALRP
            namespace and the domain identifier field in the signaled-domain ID

#4 - another suggestion I haven't thought of...?... please make it

James

---

From: ken carlberg <[email-masked]>
Date: Wed, 12 Sep 2007 16:06:33 -0400

> (with my individual hat on)

I may do my best impression of William Tell on that individual hat of  
yours ;-)

before I or anyone responds to this email concerning the potential  
conflect, I'd like to make a plea for you to respond point-by-point  
to the list on the comments I made on your signaled-domain draft back  
in July 20'th.

A number of the comments can be brief and you can just mention that  
you addressed this or that in your presentation at the Chicago-IETF.   
But that presentation didn't respond to all the questions I raised.   
So it would help me at least to get some feedback on my July 20'th  
email before I get back to the topic at hand.

and by the way, my gut feeling is that I don't think there is a  
conflict, but I'll hold off for now.

-ken