Subject: Re: [mpls] Question regarding draft-ietf-mpls-tp-mip-mep-map-01

From: Rolf Winter <[email-masked]>
Date: Mon, 16 Jul 2012 11:36:52 +0000

Hi Muly,

apologies for not replying earlier. The authors of the draft have discussed this issue and we think we have found a suitable solution. We have added a note to the draft and will add the solution in the next version of the document. 

Thanks (and sorry again for the really really long delay of the answer),

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Muly Ilan
> Sent: Dienstag, 1. Mai 2012 23:01
> To: [email-masked]
> Subject: [mpls] Question regarding draft-ietf-mpls-tp-mip-mep-map-01
> 
> Dear Authors,
> 
> 
> 
> For the per-interface MIP model how do you suggest to perform a route
> tracing over a static MPLS-TP LSP?
> 
> 
> 
> According to RFC6371 section 6.4 "Route tracing should always discover
> the full list of MIPs and of peer MEPs".
> 
> RFC6424 section 4 specifies a method for route tracing using LSP-Ping.
> It explains to use MPLS TTL expiry to reach a specific node.
> 
> 
> 
> Your solution to address a specific in-MIP or out-MIP is to include the
> MIP identifier in the sent OAM packet. RFC6424 defines extensions to
> LSP-Ping, in the form of new TLVs and sub-TLVs, that allow to identify
> the target MIP within the node.
> 
> However, for a static MPLS-TP LSP the MIP identifiers along the path
> are not known at the head-end prior to performing the route tracing and
> receiving the LSP-Pings echo responses.
> 
> Seems like a chicken and egg issue.
> 
> 
> 
> I hope that there's a more elegant way than having the management plane
> configure all the relevant path identifiers at the head-end before
> attempting a route trace.
> 
> 
> 
> Regards,
> 
> 
> 
> Muly Ilan