Re: QoS NSLP Proxy mode

Roland Bless <[email protected]>
Newsgroups gmane.ietf.nsis
Organization Institute of Telematics, University of Karlsruhe
Message-ID <[email protected]>
Hi Jukka,

Jukka MJ Manner wrote:
> 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).

Aside from the magic knowing that the QNR is not the end host, it's
actually clear so far.

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

Do you have an example for this?

> 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 

What trick? I was not aware of mentioning one...

> 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 

Yes, that's actually the draft saying that the QNE is configured to act
as proxy for certain end systems. I don't see a big problem with that
information, probably it is well known which terminals support NSIS and
which don't. That would be important for supporting a migration scenario
allowing for increasing NSIS deployment.

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

Yes, every case where you have different configured proxies in
different domains will make it difficult with the scope concept.
On the other hand, NSIS is usually designed for e2e signaling, so
I think it is not very uncommon to cross various domains.

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

That would be great.

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.