6. Hierarchy bis - Signaled FAs CCAMP, IETF64 Kohei Shiomoto:

Advertisement of hierarchical and stitchable LSPs as TE Links draft-shiomoto-ccamp-lsp-hierarchy-bis- 00.txt CCAMP, IETF 64 K. Shiomoto: R. Rabbat: A. Ayyangaer: A. Farrel:

3 Preface -Discussion hints Background reading draft-ietf-mpls-lsp-hierarchy-08.txt  RFC4206 draft-shiomoto-ccamp-lsp-hierarchy-bis-00.txt what is the problem with the hierarchy draft? is this a problem we need to solve? do we need dynamic, numbered, bidirecitonal LSPs? are there other associated problems (e.g. dynamic bundling) do we need to solve those problems? why not use LMP? why discuss here and not in MPLS?

4 Dynamic Numbered FA procedure [RFC4206] Assuming a dynamically signaled bidirectional FA-LSP setup, The ingress LSR can advertise a forward TE-link right after the LSP is setup. The egress LSR has to wait to advertise the backward TE-link until it receives the advertised forward TE-link. Even, it does not know whether it should advertise the backward TE-link or not! Today’s procedure [RFC4206]: 1. The ingress signals the LSP using a /31 sender address that it allocates. 2. The egress sets up the LSP. 3. The ingress then forms FA out of that LSP by advertising it as a TE-link. Toward that end, it uses IGP to advertise the TE link using the /31 address. The head-end address of the FA-LSP is specified in the IPv4 tunnel sender address in the Sender Template Object of the FA-LSP. 4. When the egress receives the advertised TE-link, it checks whether it is the endpoint of the TE-link. 5. The egress then advertises the TE-link setting the advertising TE Router ID in the Link-ID and the assigned /31 address in the local interface address.

5 What is the problem? In order that the egress of an LSP can advertise the LSP as a TE link, it needs to know that such an advertisement is desirable, and it also needs to know the TE Router ID of the ingress LSR [RFC3630]. How do we know if the advertisement is desirable or not? How do we know the TE-router ID? For the numbered FA, there is no place in the RSVP messages to carry the TE Router ID of the ingress LSR. Therefore the egress LSR has to wait to receive the TE-link advertisement by the ingress LSR to learn the TE Router ID. The egress LSR has to check all received advertisements in case they match the egress of an LSP

6 How about unnumbered? For unnumbered TE links this information is available using the mechanisms in [RFC3477]. If the LSP_TUNNEL_INTERFACE_ID object is present, it indicates that the LSP is to be advertised as a TE link, and it contains the TE Router ID of the ingress LSR. However, for numbered TE links, the mechanism in [RFC4206] does not provide this information. Because the LSP_TUNNEL_INTERFACE_ID object is not defined there is no trigger for TE link advertisement on the egress.

7 Why not extend this mechanism? LSP_TUNNEL_INTERFACE_ID Object Extend it as follows. C-Type Meaning Reference Unnumbered interface identifier [RFC3477] 2 (TBD) IPv4 interface identifier with target [2.3.2, HIER-bis] 3 (TBD) IPv6 interface identifier with target [2.3.3, HIER-bis] 4 (TBD) Unnumbered interface with target [2.3.4, HIER- bis]

8 How about LMP? The LMP could possibly be run on remote adjacencies between the endpoints of the LSP. LMP peer discovery is required for dynamic LMP peering. Remote LMP adjacency remains unproven. All regions/layers in an MRN/MLN network is required to run LMP.

9 Discussion hints what is the problem with the hierarchy draft? is this a problem we need to solve? do we need dynamic, numbered, bidirecitonal LSPs? are there other associated problems (e.g. dynamic bundling) do we need to solve those problems? why not use LMP? why discuss here and not in MPLS?