Re: QoS NSLP Proxy mode

Jukka MJ Manner <[email protected]>
Newsgroups gmane.ietf.nsis
Message-ID <[email protected]>
Hi Roland,

The proxy concept is meant to be used in deployments where we (somehow, 
magically) know that the QNR will not answer the signaling. The recent 
work on RSVP proxies lists several actual deployment cases where proxies 
would work. Sure, you can set up your network such that a certain QNE 
always stops the signaling and possibly replies with RESPONSE (acting as 
a P-QNE).

The use of an explicit bit is meant to make this case clearer in 
mixed-mode scenarios, where some signaling can be e2e and some only local, 
proxied.

The scenario your draw is an example which is difficult to solve, since 
the two domains would need to know about each other. The trick you 
mentiond could be a further refinement, but you make the expectation that 
the QNE in domain 2 knows that the receiving node will not be NSIS aware 
and will not be able to reply with a RESPONSE. The case of nested proxies 
is a difficult one since you would need to have somekind of e2e awareness 
for the last proxy on the path to know there is not QNE beyond it. The 
proxy flag does not cover this case.

The text is not very clear on this, and the "dual use", we'll fix this in 
the next revision, after Magnus's AD review.

Thanks for the comment,
Jukka

On Thu, 10 Jul 2008, Roland Bless wrote:

> Hi,
> 
> just a quick question for sec 4.8:
> I find the dual use of the Proxy flag somewhat confusing.
> In particular the draft says:
> 
>    For outgoing data flows and sender-initiated reservations, the end
>    host is the QNI, and sends a RESERVE with the PROXY scope flag set.
>    The P-QNE is the QNR, it will receive the RESERVE, notice the PROXY
>    scope flag is set and reply with a RESPONSE (if requested).
> 
> a) How can an initiator know that a P-QNE will answer instead of the
>    destination end host? (probably the have a prior appl. level
>    signaling, but I think it would not be necessary to set the
>    proxy bit in the RESERVE).
> 
> b) If there is the following use
>    "certain region, e.g., for an administrative domain.  A node
>    initiating the signaling may set the PROXY scope flag to indicate
>    that the signaling is meant to be confined within the area controlled
>    by the proxy, e.g., the local access network."
>    it may actually conflict with the situation in a) where the QNI
>    set the P-bit to indicate proxy use in its domain.
> 
> Assume A is the QNR and has to set the P-bit in the RESERVE because
> B is not NSIS capable, then Domain 1 may use the P-bit
> as scoping indication and drop the RESERVE?
>    ---                ------
>  /    \              /      \
> |A   P |--> .... -->|   P    | B
>  \    /              \      /
>   ----                ------
> Domain 1             Domain 2
> 
> My intuitive understanding of a proxy-mode would be:
> QNI A sends a normal RESERVE and QNE P in Domain 2
> intercepts the RESERVE and acts as proxy (P-QNE) for B.
> Thus it sets the P-Bit in the RESPONSE (if one was requested).
> A will see that P-bit is set and so conclude that it wasn't
> really B who sent the RESPONSE. However, I don't see the
> need that A must set the P-bit if the P-QNE in Domain 2
> is configured to act as proxy for B.
> Furthermore, I would recommend to remove the scope overloading
> function of the P-bit as its use would be ambiguous.
> Could someone clarify on that, please?
> 
> Regards,
>  Roland
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.