Re: [mpls] [PWE3] [mpls-tp] mpls wg last call ondraft-ietf-mpls-tp-identifiers-01

[George Swallow <[e-mail]>]

In line -


On 5/6/10 2:08 PM, "venkatesan mahalingam" <[e-mail]> wrote:

> Hi George,
>>> >> 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.
> VM: Can you please explain the original intention with an example?
> 
> The original intent was to allow a compact form for a globally unique MEP-ID
> that is,
> 
> Node_ID::Tunnel_Num::LSP_ID would be unique within an operator.  This requires
> that Tunnel_Num be unique to the node (not the node pair).  That makes it
> impossible to coodinate the Tunnel_Num spaces across nodes, hence two tunnel
> numbers.
> 
>>> >> -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.
> VM: Do we need extensions in the RSVP-TE signaling to carry back the
> destination's tunnel_num in the RESV message?
> 
> Yes, this and probably quite a few more.   Note that there is a draft for
> adding signaling of OAM capabilities in the works.
> 
> ...George
> 
> Thanks,
> Venkatesan Mahalingam
> 
> On Fri, Apr 16, 2010 at 10:15 PM, George Swallow <[e-mail]> wrote:
>> 
>> 
>> 
>> 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
>> 
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
> 
>