Subject: RE: Clarification on Handling a specific event in LDP

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Wed, 18 Sep 2002 11:38:36 +0530

Kannan,
This is a special case. 

I have a solution for this problem.
Basically if any LSR receives an Label withdraw message from its valid Next
hop neighbor then before propagating to its upstream peers it need to check
the value of the label being withdrawn, if the label happens to be an NULL
label then it should not propagate the label withdraw to its upstream peers.
Now this LSR should now assume itself as an egress for that LSP.
[Vijayanand C - CTD, Chennai.]  What will happen in valid cases when the
eggress actually wants to withdraw label and when u no longer want to switch
for that FEC ?The pennultimate hop should not hold the label in that case.
How will the Phop know for which case the withdraw applies ?   

Second one could be there should be a provision to change the label for the
particular FEC. I.e any point of time the valid next hop LSR can advertise a
change of label for that FEC. Here problems are we need to maintain the
context of that advertisement (LM).
[Vijayanand C - CTD, Chennai.]  This becomes unsolicited advertisement.

A better way would be for the egress to withdraw the label. However the
ingress will not issue a request unless it is in Independent control. This
anyway is a problem. My suggestin would be - The ingress after sending a
release can issue a fresh request for the label even if its not in
independent control if it still supports label switching on the FEC. I feel
This would be more cleaner .

Vijay

---

From: "Ramia, Kannan Babu" <[email-masked]>
Date: Tue, 17 Sep 2002 23:18:18 -0700

hi vijay..
   
thanks for ur reply ..but i still have some thing to get clarified ...
please see in line Comments
 
bye
kb
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,
This is a special case. 

[Ramia, Kannan Babu]  Actually here we are not holding the egress label, we
are sending a label release for the corresponding withdraw message and also
i am expecting only the INGRESS will start the LSP deletion process for any
genuine case (of course assumption is all LSR is configured with the
forwarding of the label release)

[Ramia, Kannan Babu] i dont see any problem in this kind of advertisement,
even if u are configured with DOD ordered mode if any change in hop count or
PV, the downstream LSR will anyway generate a LM with out any outstanding
LR. So i want to treat the change in label also the same way as that of
change in hop count.

[Ramia, Kannan Babu]  How the ingress will know that it need to request
again or initate LSP establishment once again for the same FEC (i mean here
what criteria or conditions it checks before it does this again..) because
in some genuine cases if egress wants to remove the LSP then it may lead to
infinite looping.

Vijay

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Wed, 18 Sep 2002 12:15:18 +0530

See my comments inline
-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:48 AM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

hi vijay..

bye
kb
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,
This is a special case. 

[Ramia, Kannan Babu]  Actually here we are not holding the egress label, we
are sending a label release for the corresponding withdraw message and also
i am expecting only the INGRESS will start the LSP deletion process for any
genuine case (of course assumption is all LSR is configured with the
forwarding of the label release)
[Vijayanand C - CTD, Chennai.] By holding the label I mean, the PHop would
be holding its upstream labels unnecessarily even in genuine LSP tear down
scenarios( when withdraw is received from its downstream node which is
egress) 
 Here ingress is not initiating deletion the egress does it by sending
withdraw. 

 

[Ramia, Kannan Babu] i dont see any problem in this kind of advertisement,
even if u are configured with DOD ordered mode if any change in hop count or
PV, the downstream LSR will anyway generate a LM with out any outstanding
LR. So i want to treat the change in label also the same way as that of
change in hop count.
[Vijayanand C - CTD, Chennai.] Changing the attributes of the label mapping
( like PV) is different from changing the label itself. Again the context
maintenance (old label, FEC) for this is a problem as you said. Even the
question of communicating changed attributes seldom arises in DOd Ord
control. In cases where it happens, such as Next hop change, it was debated
at length earlier in this list if it was proper to unsolicitedly advertise
the changed attributes.

[Ramia, Kannan Babu]  How the ingress will know that it need to request
again or initate LSP establishment once again for the same FEC (i mean here
what criteria or conditions it checks before it does this again..) because
in some genuine cases if egress wants to remove the LSP then it may lead to
infinite looping.
[Vijayanand C - CTD, Chennai.] This kind of situation( retrying) will anyway
apply in Independent control( all nodes along the LSP may potentially
retry). So how will you solve the problem in that case ?  What I am
suggesting is if ordered control is used the retry can be done only by the
ingress. Any retry mechanism would have some back off and stopping criteria
associated with it implicitly.

Vijay

---

From: "Ramia, Kannan Babu" <[email-masked]>
Date: Wed, 18 Sep 2002 01:50:03 -0700

See my inline Comments
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 12:15 PM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my comments inline
-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:48 AM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

hi vijay..

bye
kb
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,
This is a special case. 

[Ramia, Kannan Babu]  [Vijayanand C - CTD, Chennai.] By holding the label I
mean, the PHop would be holding its upstream labels unnecessarily even in
genuine LSP tear down scenarios( when withdraw is received from its
downstream node which is egress) 
 Here ingress is not initiating deletion the egress does it by sending
withdraw. 

[Ramia, Kannan Babu]  I have one more idea for differntiating a genuine
withdraw to the special withdraw. i.e if the LSR A sends a label with draw
message to LSR B with the FEC-X and label TLV has label value IMPLICIT NULL
and in the optinal paramters it can send a changed label value to be used,
there by we can differntiate from the genuine case (in genuine case the
optinal paramter wont contain any label) to the special case. if we have
this check in the label withdraw procedure it will solve our problem. This
solution wont distrub the LSP setup where as the ingress retry solution will
distrub the LSP, which is undesiarable one also we need to provide the
checking criteria for re-establishing the LSP.

 

 

Vijay

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Wed, 18 Sep 2002 14:49:28 +0530

Again you are overriding the Dod Ord control by using a label map along with
a withdraw whereby  it becomes an unsolicited mapping.
Apart from the Question of syntactical correctness of sending an unsolicited
label map there is another problem.
 The domain in configured for Dod Ord. THis may be due to constraints in the
switches to install labels. For example, in GMPLS, the set of desired labels
is sent along with the request indicating the range of labels the upstream
can switch onto. Hence the Dod Ord control has significance in such
scenarios' and overriding it may cause confusion.
 
The issue of change in next hop for an FEC right at the egress( which is
usually egress for routing domain) is a very rare situation and I think it
does nt warrant drastic changes to the semantics and operation of LDP
 
Vijay
-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 2:20 PM
To: 'Vijayanand C - CTD, Chennai.'
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my inline Comments
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 12:15 PM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my comments inline
-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:48 AM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

hi vijay..

bye
kb
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,
This is a special case. 

 

 

Vijay

---

From: [email-masked]
Date: Wed, 18 Sep 2002 10:58:30 +0100

2 questions....please see below.  regards Neil
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: 18 September 2002 10:19
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

NH=> How does PHP work with GMPLS? 
 
The issue of change in next hop for an FEC right at the egress( which is
usually egress for routing domain) is a very rare situation and I think it
does nt warrant drastic changes to the semantics and operation of LDP 
NH=> If you stopped using PHP would this problem not 'go away'?
<snipped to end NH>

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Wed, 18 Sep 2002 15:54:09 +0530

I am not stating that PHP is used in GMPLS. I am just stating that using
unsolicited mappings in Dod Ord scenarios is not advisable. If unsolicited
mappings were allowed for this PHP problem it would encourage application to
similar problems.It would allow the flexibility for LSRs to change labels
allocated unsolicitedly in a strictly Dod Ord domain.
 
Please correct me if I am wrong
 
Regards,
Vijay

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 18 Sep 2002 09:26:03 -0400

Vijay/Kannan,

            Please see below...

Eric W. Gray

Systems Architect

Celox Networks, Inc.

[email-masked]

508 305 7214

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]] 
Sent: Wednesday, September 18, 2002 5:19 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

There are cases in which DoD vs DU distribution and Ordered vs Independent
control

become rather vague distinctions.  That is the problem hidden behind the
fact that

people talk past each other on this topic, rather than talking to each
other.

Rather than talking about the gross terms, consider the details of
implementation

you are likely to encounter. If the negotiated mode between two LSRs is DoD,
then

each LSR is required to accept one or more Label Request messages for each
FEC

and neither is required to accept _any_ unsolicited Label Mapping messages.
The

LSR that receives an unsolicited Label Mapping may decide to immediate
release

it - or worse yet - it may assume the peer has become confused and tear down
the

LDP session. This is in essence the problem that Vijay is probably concerned
with.

However, there is always the robust notion of being generous in what you
accept.

While, IMHO, the LSR that sends an unsolicited Label Mapping when in DoD
mode

is generally in the wrong, it seems _very_ un-robust behavior to terminate
the LDP

session and it might be more robust to at least retain the new Label Mapping
(yes,

even if in conservative retention mode - thus blurring another distinction).
In fact,

it is likely that some implementations will treat such an unsolicited Label
Mapping

as an implied Label Withdraw (though - with effort - I can dredge up an old
E-Mail

message in which members of the LDP design team were adamant that this was 

not the way it is intended to work).

In the case Kannan is pointing out, the retention of the new Label Mapping
(in case

the previous one is withdrawn) is very much more robust than almost anything
else 

you might do (with the possible exception of using it as an implied
Withdraw).  If

the new Label Mapping is not retained, then the LSP is removed edge to edge
and

must be re-established.  

This - by the way - is exactly the behavior originally intended in the DoD,
Ordered 

control mode: LSR A in Kannan's case would Withdraw all Labels associated
with

forwarding toward the newly discovered peer LSR C and then wait for all
affected

ingress LSRs to send Label Requests to re-establish LSPs.  I brought this up
with 

the LDP design team 3 years ago and many of them agreed that this would not
be 

good behavior.  However, it was not clear that any other behavior should be
explicitly

specified.

Vijay

-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 2:20 PM
To: 'Vijayanand C - CTD, Chennai.'
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my inline Comments

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 12:15 PM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my comments inline

-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:48 AM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

hi vijay..

bye

kb

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,

This is a special case. 

 

 

 

Vijay

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 18 Sep 2002 09:27:50 -0400

Eric,

	This did not slip between the cracks, it was pushed.

	:-)

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2002 8:52 AM
> To: Ramia, Kannan Babu
> Cc: MPLS (E-mail)
> Subject: Re: Clarification on Handling a specific event in LDP
> 
> 
> I think this case slipped through the cracks, because the use of LDP in
> DoD/Ordered mode was envisioned for use in networks consisting of ATM-
> LSRs, which of course don't do PHP.
> 
> Is this a practical problem for you, or simply a theoretical one?

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 18 Sep 2002 09:35:16 -0400

This would be a great topic for an RFC next April...

Eric W. Gray

Systems Architect

Celox Networks, Inc.

[email-masked]

508 305 7214

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: 18 September 2002 10:19
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

<snipped to end NH>

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 18 Sep 2002 13:00:43 -0400

Dan,

	The distinction between terminating LSPs and
non-terminating LSPs is not always readily apparent.
One of the scenarios I pointed out (much) earlier
is the one in which LDP is 'turned on' in a router.
This has the effect of changing a routing peer into
both a routing and LDP peer.  It also changes LSPs
that previously terminated on surrounding routing
peers into non-terminating LSPs. 

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> From: Dan Tappan [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2002 12:48 PM
> To: Jack Brennen
> Cc: MPLS (E-mail)
> At 11:56 AM 9/18/2002 -0400, Jack Brennen wrote:
> >It seems to me that any of these behaviors should be allowed; the
> >upstream peer should not interpret any of these behaviors as a
> >fatal error.  Additionally, it seems evident that any of these
> >behaviors is "acceptable" -- the data flow in question should be
> >correctly forwarded regardless of which behavior is chosen.
> 
> Actually, that point is arguable. In fact, in the case where the LSP in
> question didn't terminate at this LSR, i.e. where the FEC did not
> correspond to the LSR or to one of its connected interfaces, then
> advertising a NULL label at all will not produce correct forwarding
> behavior in the presence of a label stack.
> 
> So, the "correct" behavior is more like:
> 
> (1a) Advertise NULL labels only for terminating LSPs. For non-terminating
> LSPs, always advertise a non-NULL label even if no label has been received
> from the next-hop.
> 
> 
> >Eric Rosen wrote:
> > >
> >It's an implementation detail for any implementor whose LSR gives out
> >NULL labels (either implicit or explicit).  Specifically, what should
> >the behavior be when a NULL label has been sent upstream, and a "real"
> >(non-NULL) label becomes available from the next hop (either through
> >a next hop change or through receipt of a Label Mapping or an Address
> >message)?  How is the behavior modified by the three major "knobs" of
> >LDP (DoD/Unsolicited, Ordered/Independent, Liberal/Conservative)?
> >
> >RFC 3036 is silent on the matter, so I would assume that the behavior
> >is implementation-dependent, with the following possibilities (there
> >may be more, but these come to mind):
> >
> >   (1)  Avoid the issue -- don't send NULL labels.  :-)
> >
> >   (2)  Leave the NULL label in place; take no action.
> >
> >   (3)  Withdraw the NULL label; readvertise using a non-NULL label
> >        only if the session supports Unsolicited advertisement.
> >
> >   (4)  Withdraw the NULL label; readvertise using a non-NULL label
> >        regardless of the session's advertisement setting.
> >
> >   (5)  Advertise using a non-NULL label, without withdrawing the
> >        NULL label.  The upstream peer *might* realize what you are
> >        trying to do...
> >
> >It seems to me that any of these behaviors should be allowed; the
> >upstream peer should not interpret any of these behaviors as a
> >fatal error.  Additionally, it seems evident that any of these
> >behaviors is "acceptable" -- the data flow in question should be
> >correctly forwarded regardless of which behavior is chosen.
> >
> >     Jack

---

From: Dan Tappan <[email-masked]>
Date: Wed, 18 Sep 2002 13:43:14 -0400

>peers into non-terminating LSPs.

You're missing the point.

If the FEC in question corresponds to the LSR advertising the label, then 
it is appropriate to advertise a NULL label.

If the FEC does _not_ correspond to this LSR, then advertising a NULL label 
will cause the LSP to terminate prematurely. So, if a packet contains a 
label stack the underlying label will be exposed prematurely, causing it to 
be interpreted by an LSR other than the one which advertised it.

With your example, given

  LSR_A --- LSR_B

----LSPx----->

Where the path for LSPx goes through LSR_B. Turning on LDP in LSR_B does 
not change the LSP from "terminating" to "non-terminating" as far as LSR_A 
is concerned, in either case the next hop for the LSP goes through LSR_B. 
What it changes is whether or not LSR_A has received a valid label from the 
next hop. So, LSR_A can always advertise a non-NULL label, but it may 
change the forwarding behavior for that label depending on what it learns 
from LSR_B. It may also change whether LSR_A is the "egress" for LSPx, and 
so may affect whether or not LSR_A even advertises a label at all if in 
Ordered mode, but that is a separate issue from whether or not the 
advertised label should be null.

If the complete corner case we're worrying about is:
- DoD
- Ordered
- LSR_A changes from Egress to non-egress for an LSP

Then the correct behavior was:
- advertise a non-null label while egress (because the LSP did not terminate)
- if LSR_B starts to run LDP, meaning LSR_A realizes it is no longer 
egress, then withdraw the label. Presumably the upstream LSR(s) should 
re-request the mapping (see the last sentence in the "Summary" of RFC3036 
A.1.5), in which case the existing state machine applies.

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 18 Sep 2002 14:01:22 -0400

Eric,

	Please see below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> ---

[snip]
Jack> (5)  Advertise using a non-NULL label, without withdrawing the
Jack>      NULL label.  The upstream peer *might* realize what you are
Jack>      trying to do...
> 
> This will probably upset the peer.

That depends on what you mean by "upset".  Assuming we do
not have to worry about the defective implementation case,
the worst that could happen is for the peer to decide that 
the session is compromised and reset it.  That would be BAD,
but it would also be very unusual.

Any reasonably robust implementation would simply release
the unsolicited label mapping if it does not know what else
to do with it.

> 
> Once you withdraw a label, you have to wait for the upstream 
> peer to request a new label.  The upstream peer could 
> probably get away  with requesting a new label immediately,  
> not percolating the withdraw upstream unless the new  
> request is refused.  Or the upstream peer could just percolate
> the withdraws upstream, in which case the ingress would have to  
> reinitiate a request.  I don't really see what else could be 
> done without causing interoperability problems.

This case does not have the LSR withdraw the label.  Even
if the LSR does withdraw the label after advertising a new
one (assuming it does not get a release for either of the
outstanding Label Mappings), by that time, the upstream 
LSR should have a replacement label and will not need to
either request one or withdraw corresponding labels from
upstream LSR peers.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 18 Sep 2002 14:00:08 -0400

>peers into non-terminating LSPs.

         Shouldn't the labels bound to these LSPs be withdrawn
and be re-requested?

         --Tom

>[email-masked]

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 18 Sep 2002 14:28:49 -0400

Dan,

	Please see below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> Sent: Wednesday, September 18, 2002 1:43 PM
> To: Gray, Eric
> Cc: Jack Brennen; MPLS (E-mail)

I personally have no problem with this statement.  However, 
there are some implementers who will feel it is excessively 
restrictive.

While it is true that an LSR should not give out an implicit 
NULL label if it is not the terminating point for an LSP on 
which it may receive either labeled traffic or a mix of labeled 
and unlabeled traffic, there are many scenarios in which an LSR 
will be in a position to know that there are no other labels in 
the stack.  This is the case, for example, if it is currently 
the end point for an LSP on which it is getting IP packets that 
it is then forwarding as IP packets on some other interface.

But this is obvious.  What are you really getting at?

> 
> If the FEC does _not_ correspond to this LSR, then advertising a NULL
> label will cause the LSP to terminate prematurely.  So, if a packet 
> contains a label stack the underlying label will be exposed prematurely, 
> causing it to be interpreted by an LSR other than the one which 
> advertised it.

There is nothing implying the existence of a label stack in
this discussion.  The egress LSR is simply forwarding LSP
packets using IP and subsequently discovers that it could
start forwarding them using MPLS.  If there was a mixture
of IP and MPLS labeled traffic being received on the LSP,
the LSR was already presumably dealing with this.

> advertised label should be null.

If you drop the fact that we are discussing DoD behavior
rather than DU behavior, I once had this same discussion 
with one of your colleagues at Cisco only with reversed
roles.  It is certainly arguable that the need to support
PHP is just is great in the DoD case as it is in the DU
case.  What may be a little harder to justify (I think
this was Eric Rosen's point earlier) is whether there is
as much need to support DoD as there is to support DU in 
any case where there is a need to support PHP.

Once you accept the fact that there is a legitimate need
to support PHP, then the restriction that it can only be
used when the LSP is for a FEC corresponding to the LSR
_is_ excessive.

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 18 Sep 2002 13:43:32 -0400

Jack et al,

	Please see comments below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> From: Jack Brennen [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2002 11:56 AM
> To: MPLS (E-mail)

This is a rational approach, particularly when there is a next
hop that may become an LDP peer (even theoretically).  However
it is not an option for some implementations.

>   (2)  Leave the NULL label in place; take no action.

This works for implementations that do not 'suffer' with
the overhead of providing LSP ingress.  Otherwise, it is
sub-optimal.

>        only if the session supports Unsolicited advertisement.

In the DoD/Ordered control case - strictly interpreted - this 
is the implied behavior and would result in tearing down all 
affected LSPs to ingress and waiting for the ingress LSRs to 
start over for each LSP.  Because the local LSR should not be
in the business of trying to predict the distribution/control
modes of upstream LSRs (beyond the immediate peer), it should 
behave as if upstream LSRs are observing the same behavior as 
its immediate upstream LSR peer - both because this is one 
reasonable assumption and it is the worst case.  Using this 
assumption, the behavior of Withdrawing the Implicit NULL label 
(just to remove the growing ambiguity in this thread) should be 
considered sociopathic.

>        regardless of the session's advertisement setting.

See response to 3 above.  This is slightly less pathological
in the sense that it is possible that LSPs will take less 
time to be re-established.  It is slightly more pathological
given the possibility that some implementations may simply
release any label they receive unsolicited - you still end
up waiting for the ingress LSRs to re-establish LSPs and you
also end up with a great deal more signaling.

>        NULL label.  The upstream peer *might* realize what you are

Indeed, and this behavior is harmless in the event that the
upstream peer does not.  I have previously referred to this 
as implied withdraw.  There are reasons why 'implied withdraw' 
may not work in general.  For example, how does this work if
more than one label has previously been given for the same
FEC?  However, in the case where the one and only previously 
advertised label was the implicit NULL label (which had zero
- or possibly negative semantic value), this behavior will
work nicely.

Moreover, if the upstream LSR does not know what to do with
the label, it will simply release it (potentially telling 
the local LSR not to bother trying this again) and subsequent
behavior is no worse than it would be otherwise.

The downstream LSR should do one other thing.  Because the 
upstream LSR may be 'conservatively' implemented, it may 
simply 'liberally' retain the new Label Mapping.  Hence, 
the local LSR must withdraw the implicit NULL label if
the upstream LSR does not release it within some period of 
time.

Note that - if you cruise through the appendices in RFC 3036
- you should find that things work out correctly when done
this way.

> correctly forwarded regardless of which behavior is chosen.

In the standards process, anything not explicitly forbidden
is implicitly allowed.  Sometimes things which are explicitly
forbidden are implicitly allowed if undetectable.  Finally,
even if a thing is never allowed, it may not be advisable to
assume that it is not done.  :-)

---

From: "Ramia, Kannan Babu" <[email-masked]>
Date: Wed, 18 Sep 2002 21:01:17 -0700

Sorry.. due to the time zone difference i didnt look at your resposes.. Here
are my view point on the solution.. please see below
 
-----Original Message-----
From: Gray, Eric [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 6:56 PM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Vijay/Kannan,

            Please see below...

Eric W. Gray

Systems Architect

Celox Networks, Inc.

[email-masked]

508 305 7214

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]] 
Sent: Wednesday, September 18, 2002 5:19 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

must be re-established.  

[Ramia, Kannan Babu]  here i am using the Label Withdraw message (which is
again doesnt lose any context) as my implied Label mapping message in
addition to its withdrawing function, but here only difference is that
implied label mapping may not have any out standing label request so in the
sense it is unsolicited label mapping. But in this case the main difference
will be this label mapping is not a pure Unsolicited case because it has the
context of the LSP it refers. so i dont see this procedural changes should
not confuse the LSRs operating in DOD ordered mode.

specified.

Vijay

-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 2:20 PM
To: 'Vijayanand C - CTD, Chennai.'
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my inline Comments

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 12:15 PM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my comments inline

-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:48 AM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

hi vijay..

bye

kb

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,

This is a special case. 

 

 

 

Vijay

---

From: "Ramia, Kannan Babu" <[email-masked]>
Date: Wed, 18 Sep 2002 21:02:43 -0700

HI vijay..
 
    i didnt understand why PHP behavior will come in GMPLS..in GMPLS we are
using actual resources as our labels..so i dont think this case is
applicable to GMPLS.

bye
kb
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 2:49 PM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

 
Vijay
-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 2:20 PM
To: 'Vijayanand C - CTD, Chennai.'
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my inline Comments
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 12:15 PM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

See my comments inline
-----Original Message-----
From: Ramia, Kannan Babu [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:48 AM
To: 'Vijayanand C - CTD, Chennai.'; Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

hi vijay..

bye
kb
-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 11:39 AM
To: Ramia, Kannan Babu
Cc: [email-masked]
Subject: RE: Clarification on Handling a specific event in LDP

Kannan,
This is a special case. 

 

 

Vijay