Hi Adrian, What do you suggest the path forward from here regarding this issue? Should we just put it in an Errata?
Thanks, Vishwas On Fri, Sep 11, 2009 at 10:01 AM, Vishwas Manral <[email protected]> wrote: > Hi Adrian, > > It would have been ok if it was a connectionless transport like UDP. > > However I notice a problem when I want multiple sockets to use the > same port number in particular cases. I figured that I cannot have a > server socket (accepting connections) as well as a client socket > trying to connect having the same port number, though I can allow same > port to be shared across multiple sockets in some cases by using the > socket option SO_REUSEPORT. > > Thanks, > Vishwas > > On Fri, Sep 11, 2009 at 9:33 AM, Adrian Farrel <[email protected]> wrote: >> Hi, >> >> For my part (I only worked as an author quite late in the process, but I was >> helping to get this through the IESG review that raised issued about TCP >> ports) I think Julien has not captured the point. >> >> The RFC is not silent about source ports because it does intend to limit the >> scope. >> >> As Julien says, it does matter which port is listened on, and this is >> deliberately a well-known port number so that it is not necessary to >> configure (or advertise) the port that must be called. >> >> But in Section 4.2.1 you will find... >> >> Only one PCEP session can exist between a pair of PCEP peers at any >> one time. Only one TCP connection on the PCEP port can exist between >> a pair of PCEP peers at any one time. >> >> One way to help ensure this is to reduce the number of available ports to >> use as the source port. >> >> Does restricting the source port cause any implementation or deployment >> problems? >> >> Thanks, >> Adrian >> >> ----- Original Message ----- From: <[email protected]> >> To: <[email protected]>; <[email protected]>; >> <[email protected]> >> Cc: <[email protected]> >> Sent: Thursday, September 10, 2009 9:57 AM >> Subject: Re: [Pce] PCE port number >> >> >> Hi Vishwas. >> >> Interesting comment. We must admit the wording is a bit ambiguous. >> >> RFC 5440 says: "The system listens to the PCEP-registered TCP port" and >> "Upon receiving a TCP connection on the PCEP-registered TCP port"; I do not >> see any behavior description for the source TCP port (good thing!). >> My guess is that there is no intend to put constraints on the TCP initiator >> port. I would interpret the sentence you mention as "using the registered >> TCP port on the PCE side, i.e. for the source TCP port for PCE to PCC >> messages and for destination TCP port for PCC to PCE messages"... A little >> cumbersome, I agree. >> >> Authors of RFC 5440, would there be an actual intend to specify otherwise? >> Implementers, any other interpretation? >> >> Thanks, >> >> Julien >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Vishwas Manral >> >> Hi, >> >> I looked at the following in the spec: >> >> “Transport Protocol >> >> PCEP operates over TCP using a registered TCP port (4189). This >> allows the requirements of reliable messaging and flow control to be >> met without further protocol work. All PCEP messages MUST be sent >> using the registered TCP port for the source and destination TCP >> port.” >> >> This has been worrying me a bit. Unlike other protocols like BGP or LDP >> >> In BGP it states clearly: >> >> A BGP implementation MUST connect to and listen on TCP port 179 for >> incoming connections in addition to trying to connect to peers. >> >> and >> >> BGP's destination port SHOULD be port 179, as defined by IANA. >> >> Why do we have this restriction on source port? It is becoming a >> challenging task >> in merchant OS. >> >> Thanks, >> Vishwas >> Vishwas >> _______________________________________________ >> Pce mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/pce >> _______________________________________________ >> Pce mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/pce >> >> > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
