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

[venkatesan mahalingam <[e-mail]>]

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.