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

[George Swallow <[e-mail]>]

Diego -


On 4/2/10 2:58 AM, "Diego Caviglia" <[e-mail]> wrote:

> Hi,
>    Some more comments from me more ore less on the same route as Attila.
> 
> ·         Section 1.1
> 
> o        PSC is also used as Packet Switching Capable for OSPF-TE

The term is now not used in the document, so I will take it out of the list.

> ·         Section 2
> 
> o        Tunnel I think that here a reference to the actual identifier of the
> quoted entity could help I mean a reference to Section 5

I'm going to rewrite the note.  Maybe able to work in the forward reference
you propose if I can make the text flow.

> ·         Section 4
> 
> o        would be good to have a short explanation why numbered interfaces are
> not in the scope of MPLS-TP

I'm not trying to rule them out.  Right now I'm trying to get to something
that is useable in an IP-less environment as well as an IP environment.  We
have yet to start serious work on the signaling.  We can add these if we
need them then.

> ·         Section 5
> 
> o        Even if section 2 points to 3209 than the Tunnel Identifier chosen is
> different from what is defined in 3209, Extended Tunnel ID field is missing
> while there are two different Tunnel Num that is not clear how they works.  I
> think here the same convention used in 3209 and in GMPLS signaling would be
> good to avoid to have two or more Tunnel identifiers for MPLS-TP networks
> using GMPLS. 

In section 5.3 I show the mapping to GMPLS.  The extended tunnel-id gets
filled in with the destination address.  You will note that the destination
tunnel number doesn't show up at all.  What I have in mind is that the dest
tunnel number would be carried in a new object with the semantic that this
tunnel "connects-to" a particular tunnel number at the destination.  The
object could be filled in by the source (in which case the destination would
verify and accept or reject) or left empty (in which case the destination
would return its chosen value in the RESV).

> o        Why MPLS-TP tunnels must be associated to a LIH?  Why MPLS-TP tunnels
> need to be configured as FA? Does that imply that in case OSPF-TE is used it
> must advertise MPLS-TP tunnels as FA each time a new tunnel is created?

The IF-ID names the access point to the tunnel.  PWs and LSP can be routed
through the interface (AP if you prefer).  They do not need to be advertised
in OSPF.  


> ·         Section 5.2 I think that sentence "The format of a Tunnel_ID is:"
> should be "The format of a LSP_ID is:" same for the globally unique case.

Yes.  Typo - thanks for pointing it out.

> ·         Section 5.3 addresses some of my above concern about usage of tunnel
> and lsp identifiers even if is not a 1:1 mapping given that the Dst-Tunnel_Num
> is not mapped in GMPLS Tunnel ID

Addressed above.

BR

...George

> ·         Remaining of the docs is still WP
>         
> 
> BR
> 
> Diego
> 
> 
>  line
> 
> 
> 
> DIEGO CAVIGLIA 
> Strategic Product Manager
> 
> 
> Ericsson Italy
> Product Line PAIB
> Via A. Negrone 1/A
> Genoa, Italy
> Phone [phone]
> Mobile [phone]
> [e-mail]
> www.ericsson.com 
> 
> 
> 
>  Ericsson
> 
> 
> 
> 
> 
> 
> This Communication is Confidential. We only send and receive email on the
> basis of the term set out at www.ericsson.com/email_disclaimer
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Attila
> Takacs
> Sent: venerdì 2 aprile 2010 8.54
> To: Loa Andersson; [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01
> 
> 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?
> Is it there to support associated unidirectional Tunnels/LSPs? If so it should
> be called out in the text.
> 
> Same applies to the globally unique case.
> 
> -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?
> 
> -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? This should be clarified.
> 
> 
> Hmm, maybe the Dst-Tunnel_Num should be omitted altogether.
> 
> 
> -Section 7 has a note saying to be aligned with the OAM fwk, is this still to
> be done?
> 
> -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?
> 
> -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too.
> 
> -Section 8 talks about open issues? When will these be addressed?
> 
> 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 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