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

[venkatesan mahalingam <[e-mail]>]

Hi,
>> 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?

Thanks,
Venkat.
On Thu, May 6, 2010 at 11:38 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?
>
>
> >> -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?
>
> 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
>>
>
>
>
> --
> Best Regards,
> Venkatesan Mahalingam.
>



-- 
Best Regards,
Venkatesan Mahalingam.