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

[venkatesan mahalingam <[e-mail]>]

 George,
Thanks for your response, please find the followup questions below,

Even though Dest_Tunnel_Num is primarily required for bidirectional LSP,
this is NOT required for unidirectional LSP.

In MPLS_TP environment, if user configures an unidirectional LSP (I guess
this is not a violation), then the Dest_Tunnel_Num should be ignored.

Is this a correct understanding?

And, for bidirectional LSPs, even though the Dest_Tunnel_Num is required to
identify the reverse tunnel, it need not be an INDEX to identify the
bidirectional Tunnel.

Is this a correct understanding?

BR,

--Venkat.

On Tue, Jul 13, 2010 at 2:02 AM, George Swallow <[e-mail]> wrote:

> 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]<[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.