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

From: Loa Andersson <[email-masked]>
Date: Tue, 25 Mar 2008 21:35:40 +0100

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

---

From: <[email-masked]>
Date: Wed, 26 Mar 2008 18:07:30 +0100

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