< draft-ietf-mpls-ldp-igp-sync-bcast-05.txt   draft-ietf-mpls-ldp-igp-sync-bcast-06.txt >
MPLS Working Group S. Kini (Ed) MPLS Working Group S. Kini (Ed)
Internet Draft W. Lu (Ed) Internet Draft W. Lu (Ed)
Updates: 5443 (if approved) Ericsson Updates: 5443 (if approved) Ericsson
Intended Status: Informational October 25, 2010 Intended Status: Informational November 24, 2010
Expires: April 2011 Expires: May 2011
LDP IGP Synchronization for broadcast networks LDP IGP Synchronization for broadcast networks
draft-ietf-mpls-ldp-igp-sync-bcast-05.txt draft-ietf-mpls-ldp-igp-sync-bcast-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on May 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
any protocol message changes. any protocol message changes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Computation of 'cut-edge' . . . . . . . . . . . . . . 9 Appendix A. Computation of 'cut-edge' . . . . . . . . . . . . . . 9
Appendix B. Sync without support at one end . . . . . . . . . . 10 Appendix B. Sync without support at one end . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In RFC 5443 ([LDP-IGP-SYNC]), when [LDP] is not fully operational on In RFC 5443 ([LDP-IGP-SYNC]), when [LDP] is not fully operational on
a link, the IGP advertises the link with maximum cost to avoid any a link, the IGP advertises the link with maximum cost to avoid any
transit traffic on the link if possible. When LDP becomes operational transit traffic on the link if possible. When LDP becomes operational
skipping to change at page 7, line 4 skipping to change at page 7, line 6
apply the method described in this document to broadcast networks. apply the method described in this document to broadcast networks.
Both methods can co-exist in a network. Both methods can co-exist in a network.
The techniques used in this document's solution enable LDP IGP The techniques used in this document's solution enable LDP IGP
synchronization in many scenarios where one end of the IGP adjacency synchronization in many scenarios where one end of the IGP adjacency
does not support any LDP IGP sync method. This is an optional benefit does not support any LDP IGP sync method. This is an optional benefit
and is for further study. Some ways to apply this technique to and is for further study. Some ways to apply this technique to
achieve that benefit are discussed in Appendix B. achieve that benefit are discussed in Appendix B.
7. Security Considerations 7. Security Considerations
This document does not introduce any new security considerations This document does not introduce any new security considerations
beyond those already described in [LDP-IGP-SYNC]. beyond those already described in [LDP-IGP-SYNC].
Note that in [LDP-IGP-SYNC] when a link is advertised with high
metric, an alternate path with a large number of hops can result in
the end-to-end path having more than 255 hops and thus result in
unreachability. This fact could be exploited if control of metrics
falls into the hands of an attacker.
This problem can even exist in a plain IP network with a link-state
IGP. If the directly connected path has a higher metric than an
alternate path with TTL greater than 255 hops then the standard
shortest path first algorithm will conclude that the shortest path is
the alternate path although the neighboring node is unreachable
through this path. In this case the link is advertised with its
normal metric yet there is unreachability in the network. Thus, this
document does not introduce any new issues beyond those in a standard
IGP-based IP network, and operators need to apply policy and security
to the techniques used to determine and distribute the metrics used
on links in their networks.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Conclusions 9. Conclusions
This document complements [LDP-IGP-SYNC] by providing a solution to This document complements [LDP-IGP-SYNC] by providing a solution to
achieve LDP IGP synchronization for broadcast networks. It can also achieve LDP IGP synchronization for broadcast networks. It can also
co-exist with that solution in a network that has a combination of co-exist with that solution in a network that has a combination of
p2p links and broadcast networks. It can also be introduced into a p2p links and broadcast networks. It can also be introduced into a
 End of changes. 7 change blocks. 
6 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/