Subject: Re: [mpls] wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 2 Apr 2008 03:01:39 -0400

Hi Bruno,

Thank you for the comments. Please see in-line.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 26 March 2008 13:08
> To: [email-masked]; [email-masked]
> Subject: Re: [mpls] wg last call on 
> draft-ietf-mpls-ldp-igp-sync-01.txt
> 
> Hi Markus, Alia, Luyuan, all,
> 
> A few comments:
> 
> 1) May be the document should talk about its interaction with 
> graceful restart. (I guess this document should not be used 
> when GR is used, unless GR is aborted or failed.).
> 

Very good point. Let's try to look the relationship between LDP-IGP
synch (LDP-IGP) and Graceful Restart (GR). In fact, LDP-IGP is also used
when GR is used.

There are LDP GR [RFC 3478] and IGP GR - OSPF GR [RFC 3623] and ISIS GR
[RFC 3847].

A. LDP GR and LDP-IGP synch:

LDP GR provides a mechanism to minimize the impact on MPLS labeled
traffic caused by LSR's control plane restart. LDP GR is taking the
proactive approach.

LDP-IGP synch is reactive, it provides the exchange and synch action
between LDP and IGP when LDP is already failed. It prevents router
sending traffic to the path where IGP is up and LDP is down.

There are many occasions you don't have a chance to gracefully restart.
E.g. bring up a new link; operational error - missed to configure LDP;
implementation error causes label corruption, etc. 

Both LDP GR and LDP-IGP synch provide labeled traffic protection under
different conditions.

B. IGP GR and LDP-IGP synch

IGP GR or non-stop forwarding (NSF) is to keep IGP router stay on the
forwarding path even as its IGP is restarted.

An IGP instance performing NSF should honor the LDP-IGP synch procedure
to check the LDP-IGP synch parameter on the standby routing device.

IGP GR protects traffic during the switch over. LDP-IGP protects labeled
traffic from being blackholed when LDP is faulty for some reason while
IGP is still up.

> 
> 2) " While the link could still be used for IP forwarding, it 
> is not useful for traffic with packets carrying a label stack 
> of more than one label or when the IP  address carried in the 
> packet is out of the
> RFC1918 space."
> 
> It seems that the use of RFC 1918 IP address is just an 
> example. One could find others (eg BGP free core). 
> Proposition to change to " While the link could still be used 
> for IP forwarding, it is not useful for MPLS forwarding (e.g. 
> MPLS VPN, BGP free core.)"
>

Agreed. We can used both examples.

How about we say "While the link could still be used for IP forwarding,
it is not useful for MPLS forwarding, e.g., MPLS VPN; BGP route free
core; IP address carried in the packet is out of the RFC1918 space,
etc."?
 
> 
> 3) "The LDP protocol itself has currently no means to 
> indicate to a service depending on it whether there is an 
> uninterrupted label switched path available to the desired 
> destination or not."
> 
> Eventually, it could be useful to say why LDP ordered mode + 
> FEC withdraw is not an existing mean.

LDP is not a routing protocol. IGP directs the traffic to the shortest
path regardless there is an established LSP along the path or not. Under
the LDP down and IGP up condition: When LDP Ordered Control is used, the
labeled packets drop happens at the LSR of the ingress of network as LSP
cannot be established on the shortest path selected by IGP; When
Independent Control is used, the labeled packets drop happens at the LSR
where LDP failed (could be a mid point in the LSP) as the LSP is broken.
We have seen both blackholing cases in live networks. For more details
on LDP blackholing problems and solution, also see "LDP Failure
Detection and Recovery", by L. Fang, A. Atlas, F. Chiussi, K. Kompella,
and G. Swallow, IEEE Communications Vol.42 No.10, October 2004.

> Or may be you want to say that LDP has currently no way to 
> correct the issue, for example by using a different IGP path.
> 

Yes, thanks. We can re-word this similar as you suggested: LDP has
currently no way to correct the issue. LDP is not a routing protocol, it
cannot re-direct traffic to an alternate IGP path.

> 4) "In the case of OSPF this cost is LSInfinity (16-bit value 
> 0xFFFF) as proposed in [RFC3137]."
> 
> Could you also indicate the metric to use for IS-IS?
> Especially since:
> - further in the doc you recommend that all implementation 
> use the same metric to avoid asymmetric link cost
> - RFC 3784 seems to indicate that the max metric link (2^24 - 
> 1) is already reserved
> 

Very good point.
We shall add the ISIS max metric in the draft. The max metric value for
ISIS using wide metrics is 0xFFFFFE per RFC 3784.

> 5) "It is recommended that both sides of a link implement 
> this mechanism to be effective and to avoid asymmetric link 
> costs which could cause problems with IP multicast forwarding."
> 
> Avoiding asymetric link cost during all the procedure would 
> require that both routers sharing the LDP session have the 
> same way to detect when "LDP is considered fully 
> operational". This is currently not the case.

Understood. It is a recommendation for better performance, not a
requirement.

> As the document propose to wait "some time", the document 
> could possibly propose a default value for this timer and 
> warn that if the operator wish to change that value, it 
> should change it on both side of the LDP session.
> 

We prefer not to set the hold-down timer with a default value. The
reason is that the LIB tables size can vary largely, as well the
equipment capability/speed. If the default value is too small, this
function would not work; if it is too big, it slows down the convergence
time. But the hold-down time guidelines through equipment testing would
be helpful.

LDP End-of-LIB (draft-asati-mpls-ldp-end-of-lib-01.txt) is currently a
work in progress. When End-of-LIB is implemented, it can signal the end
of IGP hold-down time, no longer need for the configured nor default
timers. 

> Also, as there is a risk of transient asymetric link cost 
> (because the end of the procedure is not stricly defined) 
> could you possibly provide more precision on the problems 
> that could be faced by IP multicast?
> 

Yes, transient asymmetric cost is always a risk, it is not just for this
problem, it is rather a common problem. e.g. it is same as in BGP. We
would treat it as out of scope for this draft.

> Thanks,
> Regards,
> Bruno

Thanks,
Luyuan

> > From Loa Andersson
> > 
> > Working group,
> > 
> > this is to initiate a two week working group last call on:
> > 
> > draft-ietf-mpls-ldp-igp-sync-01.txt
> > 
> > Please send your comments to the working group mailing list 
> or to the 
> > working group chairs before April 11.
> > 
> > Loa and George
> > 
> > --
> > Loa Andersson
> > 
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked] 
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Mon, 14 Apr 2008 12:18:08 +0200

Hi Luyuan,

Thanks for your detailed answers.
More in-line.

Bruno

> De : Luyuan Fang (lufang) [mailto:[email-masked]]
> 
> Hi Bruno,
> 

Agreed: both GR and LDP-IGP sync have value and can be enabled on the same router at the same time.

My point was that for a given failure, only one of mechanism should take care of the failure. So if GR handle the failure, eg LDP session failure, LDP-IGP sync should not change the IGP link cost.

> to check the LDP-IGP synch parameter on the standby routing device.

Do you mean: what should we do if between two neighbor routers, IGP GR is working but is still underway while LDP GR failed?
I didn't think of this specific interaction but the subject of interaction between IGP and LDP GR procedures seems broad. I don't have detailed knowledge of IS-IS GR, but in general to stay in the safe area, it seems that the IGP topology should not change during the IGP GR procedure. So in this case, what should be the LDP-IGP sync behavior?

Note that these GR interactions are not specific to the IGP-LDP sync draft. Eg: what should we do if IGP GR succeed and BGP GR failed? (for a node proving connectivity between two ASBRs of the same AS where tunneling (MPLS or IP) is not used).

so we can probably keep this out of this draft

> core; IP address carried in the packet is out of the RFC1918 space,

Fine, thanks.

> cannot re-direct traffic to an alternate IGP path.

Fine, thanks.

> ISIS using wide metrics is 0xFFFFFE per RFC 3784.
 
Thanks.

> time. But the hold-down time guidelines through equipment testing would

You're right but this discussion could apply to lot of default timers. Eg GR timers. Yet most specification defines default values for their timers.

> of IGP hold-down time, no longer need for the configured nor default

OK, given this, I guess it's not a big deal not to define default value for the timers. May be the document could say that such LDP sync mechanism (LDP End of LIB) should preferably be used (over timers) once they are available. (in order to avoid asymmetric routing)

> would treat it as out of scope for this draft.

Ok but this document:
- Specifically states that asymmetric links cost could cause problem with multicast ("asymmetric link costs [which] could cause problems with IP multicast forwarding")
- In the short term (waiting for LDP end-of-LIB) does not fully avoid asymmetric link cost. Quite the contrary, compared to doing nothing, it creates new opportunity for this.

So could the draft just list (or reference a document describing) multicast issues with IGP asymmetric cost? Otherwise, as a service provider proving IP, MPLS VPN and multicast on the same AS, while LDP end-of-LIB is not available, I wonder if I should use this draft or not as the draft says it improves MPLS VPN availability but could create issues with multicast.