Re: [mpls-tp] Looking for alternative term for per-interface MIP

Hello Sasha,

Thanks for your promptly response.

Recently, I was confused by the definition of "MPLS-TP Section". For co-ps 
networks, I prefer the "MPLS-TP Section" should be physical links.

IMO, the "forwarding information" on "MPLS-TP Section" packets can ONLY 
identify physical links. What do you think about it?

Best regards,
steven

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> 
2010-12-10 15:00

收件人
"wei.hongbo@zte.com.cn" <wei.hongbo@zte.com.cn>cn>, Greg Mirsky 
<gregimirsky@gmail.com>
抄送
"mpls@ietf.org" <mpls@ietf.org>rg>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>rg>, 
"Italo.Busi@alcatel-lucent.it" <Italo.Busi@alcatel-lucent.it>
主题
RE: [mpls-tp] 答复:  Looking for alternative term for per-interface MIP

Steven, Greg and all,
IMHO and FWIW, the definition of Section in MPLS-TP is one of the most 
problematic ones, because it represents an attempt to hide the differences 
between data links (physical, or logical as in the case of VLANs) and 
Tunnel LSPs, by treating the former as "LSPs with the label stack of depth 
0".

Tons of confusion have already stemmed from this attempt.
The recent discussion about the requirement to carry different clients 
over a Section (after publication of RFC 5960) is just one more example of 
such a confusion.

And of course per-Section label space is yet another example of this 
confusion.

RFC 3031 has defined per-platform and per-interface label spaces; and at 
that time nobody dealing with MPLS had any doubts about what an interface 
means. 

At the same time RFC 3391 has more or less explicitly prohibited label 
space per terminated LSP when it stated that the position of the label in 
the label stack cannot affect its treatment when it is looked up.

This has been somewhat tweaked in RFC 5331 which has defined 
context-specific label spaces and "context labels" to be used in 
conjunction with upstream label allocation in LSPs crossing LAN 
interfaces.

But this is a far cry for a full-fledged "per-Section" label space when 
Section can be a terminated LSP.

The main technical reason against  is per-Section label spaces is 
scalability: 
- Existing label spaces assume that incoming labels are looked up in a 
small number of ILM supporting 1M entries each (since the number of 
interfaces and/or contexts is usually small)
- Supporting full-fledged "per-Section" label space for LSP-based Sections 
would mean that we would need (at least in theory) to implement ~1M of 
ILMs with 1M entries each. IMO this goes far beyond reason and existing 
technical capabilities.

Does this make sense to you?

Regards,
     Sasha

From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of 
wei.hongbo@zte.com.cn [wei.hongbo@zte.com.cn]
Sent: Friday, December 10, 2010 3:27 AM
To: Greg Mirsky
Cc: mpls@ietf.org; mpls-tp@ietf.org; Italo.Busi@alcatel-lucent.it; 
mpls-tp-bounces@ietf.org
Subject: [mpls-tp] 答复: Looking for alternative term for per-interface 
MIP

Hi All, 

The definition of "Section" in existing MPLS switches is refer to VLAN 
interface or physical interface? I post e-mail about this topic few days 
before, NO response. 

I think these two topic is the same thing... 

Best regards,
steven

Greg Mirsky <gregimirsky@gmail.com> 
发件人:  mpls-tp-bounces@ietf.org 
2010-12-10 09:21 收件人David Allan I <david.i.allan@ericsson.com>om>, 
Italo.Busi@alcatel-lucent.it, Adrian Farrel <adrian@olddog.co.uk>uk>, 
mpls-tp@ietf.org, mpls@ietf.org 
抄送
主题[mpls-tp] Looking for alternative term for per-interface MIP

Dear All,
throughout MPLS-TP OAM documents per-interface MIP term is used. All 
documents refer to draft-ietf-mpls-tp-oam-framework-09.txt Section 3.4. I 
think that "per-interface MIP" is not the best terminology.  "Interface", 
at least intuitively, understood as physical entity. I think that such 
interpretation is ambiguous particularly on a Merge Point in case of FRR 
or segment protection. One way to remove this ambiguity might be to 
explicitly note that "interface" and "virtual interface" are being used 
interchangeably. Another is to replace "per-interface" with another term. 
I was thinking that "per-section" might be good candidate as Section has 
been properly defined in RFC 5654.

Regards,
Greg 
_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.