Subject: Re: [Pce] Question / issue PCEP port restriction - multiple PCEP adjacencies

From: Francesco Fondelli <[email-masked]>
Date: Tue, 1 Mar 2011 18:02:45 +0100

Hi All,

Where in RFC5440 is written that a PCE MUST reject an incoming connection
if the src port is not 4189? Nowhere if I'm not wrong. Let the OS pick
a random src port and be liberal in what you accept/receive.

"All PCEP messages MUST be sent using the registered TCP port for the
source and destination TCP port" is a very unfortunate statement but it's
about *sending* not receiving.

my 2 cents
Ciao
FF

On Mon, Feb 28, 2011 at 8:10 AM, Ramon Casellas <[email-masked]> wrote:
> Fei, All,
>
> See my comments inline
>
> On 28/02/2011 7:48, [email-masked] wrote:
>
> We verify the implementation in Linux again , just as Oscar said, different
> orders give different results.
>
> As a summary: even with the use of socket options, one cannot bind a client
> socket after binding a listening socket, portably.
>
> In practice this seems to affect GNU/Linux in particular and windows / *BSD
> seem to work ok, but the fact that e.g. java programs behave differently on
> different platforms is not good.
>
>
> Just my two cents, although it MUST be careful to change the description of
> standards, it seems that we SHOULD do so to cover all kinds of scenarios and
> for easy implementation if it is necessay.
>
> I tend to agree, this is not something trivial, but we can raise the issue
> in Prague. Although it is an important change, I would say that old
> implementations that bind source ports should work without change.
>
> It does affect implementations that enforce that the (remote) source port is
> 4189.
>
> According to Christian's mail and references within, the rationale for this
> does not seem to apply anymore and the use cases have changed/evolved (i.e.
> there are use cases with 2 ore more PCC 'processes' within a node)
>
> There are two potential changes: a) do not restrict source port and b) allow
> for parallel connections between nodes, the latter no longer being
> restricted by the former.
>
> IMHO a) should be discussed, b) is a more complex change and the
> implications may be different. A given implementation may (nonconforming-ly)
> allow different connections from the same IP address (e.g. NAT?)
>
>
> All comments welcome.
>
> Thank you
>
> R.
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 01 Mar 2011 18:51:07 +0100

> a random src port and be liberal in what you accept/receive.
I agree, I was just trying to identify potential reasons for _not_ 
relaxing the requirement. It is not written, but I could not blame an 
implementor that chooses not to accept a non-compliant peer.

R

---

From: <[email-masked]>
Date: Wed, 2 Mar 2011 08:16:27 +0200

Gentlemen,

The argument presented here is the kind of argument layers make.  The 
text in RFC 5440 says, that a sender MUST use a specified source 
port, and therefore a receiver also must expect that source port and hence ignore
other source ports.  We are not layers, but technical minded people, and
technical people should make a clear statement saying, that the party initiating
a PCEP TCP session can use any source port, whereas the party 
responding (ie listening part) must listen on the specified port.

Christian
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ramon Casellas [[email-masked]]
Sent: Tuesday, March 01, 2011 7:51 PM
To: Francesco Fondelli
Cc: [email-masked]
Subject: Re: [Pce] Question / issue PCEP port restriction - multiple PCEP adjacencies

R