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

["Luyuan Fang (lufang)" <[e-mail]>]

Hi Bruno,

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of [e-mail]
> Sent: 26 March 2008 13:08
> To: [e-mail]; [e-mail]
> 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:  [phone]
> > Isafjordsgatan 22                  mobile: [phone]
> > Kista, Sweden                      email:  [e-mail]
> >                                             [e-mail] 
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 
_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls