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

[George Swallow <[e-mail]>]

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 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Loa Andersson
>> Sent: Friday, March 12, 2010 12:33 AM
>> To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
>> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01
>> 
>> All,
>> 
>> this is to start an MPLS working group last call on
>> draft-ietf-mpls-tp-identifiers-01
>> 
>> There is a discussion on the OAM model for MS-PWs where we
>> haven't been able to come to conclusion. Once we reach
>> agreement the document will be updated. Comments in this area
>> are welcome during the working group last call.
>> 
>> 
>> Please send your comments to the [e-mail] mailing list.
>> 
>> The working group last ends eob April 2nd.
>> 
>> /Loa
>> 
>> --
>> 
>> Loa Andersson
>> 
>> Sr Strategy and Standards Manager
>> Ericsson ///
>>    phone:  [phone]
>>            [phone]
>> 
>>    email:  [e-mail]
>>            [e-mail]
>> 
>> 
>> 
>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp