The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Apr> msg00139



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Doubt In Session Estb. Procedure...

  • From: "Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>
  • Date: Thu, 18 Apr 2002 10:39:41 +0530
  • Cc: mpls@UU.NET

Prem,
As per the protocol the lower value should be choosen if a diff values are
proposed.If either of them cant support this ( this is the key issue which
is the difference between the two LSRs) lower value , they can close the
session. Normally , the lower value is accepted and it works as though the
same algorithm is running at both the places. The protocol tell what to do
when an LSR cant accept the negotiated value. Its one more level of
flexibility.

Regards,
Vijay

-----Original Message-----
From: Sharma, Prem [mailto:p_sharma@trillium.com]
Sent: Thursday, April 18, 2002 1:30 AM
To: 'Vijayanand C - CTD, Chennai.'; 'eric.gray@sandburst.com'
Cc: mpls@UU.NET
Subject: RE: Doubt In Session Estb. Procedure...


Hi,

If we look at the following excerpt from the RFC 3036:

<snip>
If the maximum PDU length determined this way is unacceptable
to an LSR, it must send a Session Rejected/Parameters Max PDU
Length Notification message in response to the Initialization
message and not establish the session.
<snip>

If the passive node is sending the negotiated parameters, may be smaller of
the two (MIN(proposed by active one, proposed by itself)), then the above
condition will always pass at the active LSR and hence the session will
always establish - and hence this statements will always be redundant for
the active one.

Shouldn't it be that way that Passive one sends its own configured values
too rather than negotiated ones AND both active and passive run the same
algorithm to derive the negotiated values to use over the session. If the
derived parameters are not acceptable because of some reason or other than
the active and passive ones may terminate the session independently. This
will also help in cases where garbled parameters are received from the
passive one in response to INIT msg. from active one.

Thanks.
Prem





-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com]
Sent: Tuesday, April 16, 2002 10:14 PM
To: Sharma, Prashant
Cc: mpls@UU.NET
Subject: RE: Doubt In Session Estb. Procedure...


Hello prashant,
I think the RFC is pretty clear on this that the second Init( sent by the
passive node) will go with the negotiated value. This ensures that the
negotiation is over in a single Init by each node.

What you are suggesting is an alternative protocol. This way it will take
more than a single Init by each node. Also, if its decided that the
negotiated value is going to be the lower of the two configurations,   what
is the point in passive node sending its configuration?

Regards,
Vijay

-----Original Message-----
From: Sharma, Prashant [mailto:prashant_sharma@trillium.com]
Sent: Wednesday, April 17, 2002 8:05 AM
To: 'mpls@UU.NET'
Cc: 'eric.gray@sandburst.com'
Subject: Doubt In Session Estb. Procedure...


Hi,
     I have one doubt regarding session establishment procedure in LDP. If a
node is an active node, then
     it first sends Initialization message and the  passive node responds
with Initialization  message of its
     own. My  question is, is it mandatory for  the passive node to send
the negotiated   parameters in its
     initialization message. In other words, is it permitted that  passive
node sends its configured (and not
     negotiated parameters) in its Initialization message.In this case
active node will also be able to know
     the peer's configuration (like loop detection), if it needs to take
some action based on it. The two nodes
     can always calculate the negotiated value on receiving the peers
Initialization message. RFC is not very
     clear on this. I require this information to decide the behavior of
active node on receiving peers
     Initialization message.

     Thanks for your help in advance.

Regards
Prashant.