Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-identifiers-01

[Maarten Vissers <[e-mail]>]

George,

It is a bad practice to identify a connection (e.g. LSP) within the scope of
their server layer trail (e.g. tunnel LSP). Reason is that a connection
(e.g. LSP) is typically carried by multiple server layer trails (e.g. tunnel
LSPs). Example: a service-LSP X is carried over three transport-LSPs A,B,C:

   |<----------------service-LSP_X------------------->|
    |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->|

It is possible to reroute this service-LSP and change it as follows:

   |<----------------service-LSP_X------------------->|
    |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->|

or as follows:

   |<----------------service-LSP_X------------------->|
    |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->|

The service-LSP X is still the same service-LSP with the same service-LSP
MEP functions, only the path through the MPLS-TP network has been changed.

Identification with respect to the server layer trail (e.g. tunnel LSP) is
appropriate for a link connection (e.g. LSP segment). The service-LSP X has
three service-LSP segments. Those segments are identified with respect to
their tunnel; i.e. with respect to the transport-LSP in this example.

Regards,
Maarten

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of George Swallow
Sent: vrijdag 16 april 2010 18:45
To: Attila Takacs; Loa Andersson; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01




On 4/2/10 2:53 AM, "Attila Takacs" <[e-mail]> wrote:

> Hi Matthew and George,
> 
> Please find some comments/questions below.
> 
> -In Section 5.1 you have:
> 
> Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num
> 
> What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num?

Existing implementations of RSVP-TE have used the tunnel space as global to
the node.  It is difficult if not impossible to coordinate such spaces
between nodes.  In RSVP-TE the coordination does not matter, since the tail
end of the tunnel doesn't have a real interface - it only receives and
usually with a PHP of the tunnel label, so the packets only belong to the
physical interface.

In a bidirectional world, separate tunnel spaces at the two ends becomes
useful.  

If this independence is not need is some environments then one can configure
just one value and use it in both fields.

> Is it there to support associated unidirectional Tunnels/LSPs? If so 
> it should be called out in the text.

That was not my original intent, but you are quite correct that this would
be very useful.  Particularly if the associated tunnels pass through a share
mid-point somewhere along the path.

> Same applies to the globally unique case.

Of course.

> -In Section 5.2 you simply append one LSP_Num to the above. This is a 
> bit confusing to me, if there are Src/Dst Tunnel_Nums then two 
> LSP_Nums would be needed too, wouldn't it?

Once, you have independent tunnel-ids, coordination of the LSP numbers
becomes easy.  It also could be used to allow the two ends to readily
identify which is working and which is protection.

> -In Section 5.3 Mapping to GMPLS signaling does not use the 
> Dst-Tunnel_Num. So this means that we may have two different tunnels 
> identified with 
> Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this
intentional, e.g., the associated unidirectional case?

For the associated unidirectional, this works perfectly.  For bidirectional,
I was thinking of two options.

1)  Strict binding  -  both ends are configure with the full identifier and
will only accept the connection if everything matches.

2)  Dynamic binding - Source signals with just its Tunnel_Num.  RESV message
would carry back the destination's tunnel_num.  Note that both ends need
both pieces for some of the OAM to work.

> This should be clarified.

I'll see what I can do.  But this is not supposed to the MPLS-TP signaling
draft.
 
> Hmm, maybe the Dst-Tunnel_Num should be omitted altogether.

I'm planning to keep it.
 
> -Section 7 has a note saying to be aligned with the OAM fwk, is this 
> still to be done?

Yes.  That draft is also being updated.  We appear to be converging.

> -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs.
> How would Tunnel and LSP MEGs be used? What OAM would run at the 
> Tunnel level and not at the LSP level?
>
> Do we need Tunnel MEG_IDs as defined in 7.1.2.1?

I had been told early on that MEGs were needed for tunnels.  Now getting
comments that they are not (same comment is in the ITU liaison).  So I
planning to remove it, unless I hear other opinions.

> -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too.

See above.

> -Section 8 talks about open issues? When will these be addressed?

Before it is re-issued.  Goal is end of next week.

...George

> Thanks,
> Attila