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

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 6 May 2010 23:38:57 +0530

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 <[email-masked]> wrote:

>
>
>
> On 4/2/10 2:53 AM, "Attila Takacs" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Loa Andersson
> >> Sent: Friday, March 12, 2010 12:33 AM
> >> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> >> 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 [email-masked] mailing list.
> >>
> >> The working group last ends eob April 2nd.
> >>
> >> /Loa
> >>
> >> --
> >>
> >> Loa Andersson
> >>
> >> Sr Strategy and Standards Manager
> >> Ericsson ///
> >>    phone:  +46 10 717 52 13
> >>            +46 767 72 92 13
> >>
> >>    email:  [email-masked]
> >>            [email-masked]
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >>
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Lou Berger <[email-masked]>
Date: Thu, 06 May 2010 14:27:16 -0400

> destination's tunnel_num in the RESV message?

We are expecting the WG to come up with an explicit definition of 
signaling support for associated bidirectional within the CCAMP WG.  The 
options mentioned to date, in no particular order are:
- using association objects (draft-zhang-mpls-tp-rsvpte-ext-associated-lsp)
- using calls
- using LSP_TUNNEL_INTERFACE_ID objects

There is not yet consensus (or WG drafts) on this topic.

Lou

---

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 13 May 2010 15:23:40 +0530

Hi,
should

share

Thanks,
Venkat.
On Thu, May 6, 2010 at 11:38 PM, venkatesan mahalingam <[email-masked]
> wrote:

> On Fri, Apr 16, 2010 at 10:15 PM, George Swallow <[email-masked]>wrote:
>
>>
>>
>>
>> > confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums
>> would be
>> > needed too, wouldn't it?
>>

-- 
Best Regards,
Venkatesan Mahalingam.