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.).

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.)"

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.
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.

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

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.
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.

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?

Thanks,
Regards,
Bruno

> 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:  loa.andersson@acreo.se
>                                             loa@pi.se
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls