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

[<[e-mail]>]

Maarten...agreed...but there is also a worrying addressing problem in
all this IMO that does not seem to be recognised/understood.  In
summary, a layer network (any mode/technology, not just co-ps/MPLS-TP
say) is most essentially characterised by its access point addressing
scheme...screw this up on day 1 and it is very hard to change later.

MPLS originally never had proper addressing allocated to it...largely
due to is binding with the cl-ps mode IP layer network it could never be
seen as a layer network in its own right (part of the common
control-plane flaw - I come back on this later).  Further, each LSP here
was a *sublayer* and part of the same hybrid/MPLS/IP layer network.
Moreover, each LSP (label distribution) signalling type created its own
form of addressing for how it wanted to identify its type of access
points.

PWs made the situation significantly worse when they became multi-hop.
These suddenly jumped from an adaptation role to a full blown layer
network in their own right.  So they needed their own addressing scheme
(and OAM, LDP signalling, etc),...which is what all the AII stuff is.
Not a great addressing structure I should add, we should have used v4 or
v6 but the problem dogging this stuff was that we were still claiming
this was all part of the same IP/MPLS layer network => can also read as
same instance of routing.....something we should know now is a flawed
notion for MPLS-T based on lessons learnt from GMPLS (I originally
pointed this 'common CP nonsense' out at 2000 San Diego IETF mtg).

Now MPLS-TP is supposed to be a transport network.  So each LSP in a
nested case should be in its own layer network....this is essentially
what you shown below.  MPLS-TP therefore does not need sublayering as
per the old type of MPLS...and it for sure should not be generating a PW
layer network, that simply indicates a failure to deliver a transport
network and just propagates the error made in MPLS.

However, because some folks want to retain the S bit notion and the old
type of sublayering in MPLS-TP, we have no way of knowing whether a set
of nested LSPs belong to different layer networks or are sublayers in
some arbitary layer network grouping.  The DP looks the same in all
cases.

I can see all sorts of problems brewing here in correctly identify which
layer network a given LSP belongs to...esp if there are multiple parties
involved in both client/server and peer-partition sense. 

regards, Neil   

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Maarten Vissers
> Sent: 21 April 2010 08:11
> To: 'George Swallow'; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] [mpls] mpls wg last call on 
> draft-ietf-mpls-tp-identifiers-01
> 
> 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
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>