Hi folks, I heard this very issue came up again in the PCE, after a couple of years. Do you want me to finally put out a draft for this?
I think this is a basic change and requires a lot more then an errata, as this changes the basic protocol functioning. 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
