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

From: Greg Mirsky <[email-masked]>
Date: Thu, 9 Dec 2010 17:21:06 -0800

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

---

From: [email-masked]
Date: Fri, 10 Dec 2010 09:27:31 +0800

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 <[email-masked]> 
发件人:  [email-masked]
2010-12-10 09:21

收件人
David Allan I <[email-masked]>, [email-masked], 
Adrian Farrel <[email-masked]>, [email-masked], [email-masked]
抄送

主题
[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
[email-masked]
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.

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 10 Dec 2010 09:00:32 +0200

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: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Friday, December 10, 2010 3:27 AM
To: Greg Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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. 

Best regards,
steven

Greg Mirsky <[email-masked]> 
发件人:  [email-masked] 
2010-12-10 09:21 收件人David Allan I <[email-masked]>, [email-masked], Adrian Farrel <[email-masked]>, [email-masked], [email-masked] 
抄送
主题[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

---

From: [email-masked]
Date: Fri, 10 Dec 2010 15:28:46 +0800

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 <[email-masked]> 
2010-12-10 15:00

收件人
"[email-masked]" <[email-masked]>, Greg Mirsky 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
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.

Regards,
     Sasha

From: [email-masked] [[email-masked]] On Behalf Of 
[email-masked] [[email-masked]]
Sent: Friday, December 10, 2010 3:27 AM
To: Greg Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: [mpls-tp] 答复: Looking for alternative term for per-interface 
MIP

Hi All, 

Best regards,
steven

Greg Mirsky <[email-masked]> 
发件人:  [email-masked] 
2010-12-10 09:21 收件人David Allan I <[email-masked]>, 
[email-masked], Adrian Farrel <[email-masked]>, 
[email-masked], [email-masked] 
抄送
主题[mpls-tp] Looking for alternative term for per-interface MIP

Dear All,

Regards,
Greg 

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

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Fri, 10 Dec 2010 10:00:07 +0100

I see a lot of comments related to the term "interface" used within the OAM Framework draft in the context of the per-interface MIP definition and NO comments on the same term used within the Identifiers draft.

I would like to clarify that the same term "interface" actually represents the same concept in both the MPLS-TP Identifiers and MPLS-TP OAM Framework drafts.

I would therefore propose that the following definition is added to both drafts:

 "
Interface: An interface is the attachment point to a server (sub-)layer e.g., MPLS-TP section or MPLS-TP tunnel.
"

This definition is taken from the text in section 4 of the Identifiers draft with the following proposed changes:

1) c/Access Point (AP)/attachment point/ as proposed by ITU-T

2) c/layer/(sub-)layer/ to align the definition with the outcome of past discussion: label stacking is a form of sub-layering with the MPLS and MPLS-TP layer network.

I have a strong opinion that both the MPLS-TP Identifiers and the MPLS-TP OAM Framework must use the same term (and definition) to identify the same entity.

I have a preference to keep the term "interface" on both drafts to speed up the work.

Italo

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 10 Dec 2010 11:47:55 +0200

Italo,
Lots of thanks for a prompt response.
I agree that different MPLS-TP documents treat the term "interface" differently, and this adds to the overall havoc.

I strongly object to treating sub-layers as interfaces in MPLS-TP because IMO  this would break the MPLS data plane in an irreparable manner.

As a consequence I suggest we keep the definition used in the MPLS-TP Identifiers draft and rework the OAM framework document accordingly.

Regards,
     Sasha

From: [email-masked] [[email-masked]] On Behalf Of BUSI, ITALO (ITALO) [[email-masked]]
Sent: Friday, December 10, 2010 11:00 AM
To: [email-masked]; [email-masked]
Subject: [mpls-tp] Use of term "interface" in MPLS-TP Identifiers and OAM Framework drafts

I see a lot of comments related to the term “interface” used within the OAM Framework draft in the context of the per-interface MIP definition and NO comments on the same term used within the Identifiers draft.

I would like to clarify that the same term “interface” actually represents the same concept in both the MPLS-TP Identifiers and MPLS-TP OAM Framework drafts.

 “
“

I have a preference to keep the term “interface” on both drafts to speed up the work.

Italo

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Fri, 10 Dec 2010 13:06:38 +0100

Sasha,

The OAM Framework and Identifier drafts are already using the term "interface" in a consistent way among each other.

According to the Identifiers draft the attachment point to a server MPLS-TP Tunnel is an interface.

The change #2 I am proposing is just aimed at clarifying that the server MPLS-TP tunnel is a server sub-layer and not a server layer as per past discussion.

Italo

> -----Messaggio originale-----
> Da: Alexander Vainshtein [mailto:[email-masked]]
> Inviato: venerdì 10 dicembre 2010 10.48
> A: BUSI, ITALO (ITALO); [email-masked]; [email-masked]
> Oggetto: RE: [mpls-tp] Use of term "interface" in MPLS-TP Identifiers and
> OAM Framework drafts
> 
> Italo,
> I agree that different MPLS-TP documents treat the term "interface"
> differently, and this adds to the overall havoc.
> 
> I strongly object to treating sub-layers as interfaces in MPLS-TP because
> IMO  this would break the MPLS data plane in an irreparable manner.
> 
> As a consequence I suggest we keep the definition used in the MPLS-TP
> Identifiers draft and rework the OAM framework document accordingly.
> 
> Regards,
>      Sasha
> 
> 
> 
> BUSI, ITALO (ITALO) [[email-masked]]
> I see a lot of comments related to the term "interface" used within the
> OAM Framework draft in the context of the per-interface MIP definition and
> NO comments on the same term used within the Identifiers draft.
> 
> I would like to clarify that the same term "interface" actually represents
> the same concept in both the MPLS-TP Identifiers and MPLS-TP OAM Framework
> drafts.
> 
> This definition is taken from the text in section 4 of the Identifiers
> draft with the following proposed changes:
> 
> 2) c/layer/(sub-)layer/ to align the definition with the outcome of past
> discussion: label stacking is a form of sub-layering with the MPLS and
> MPLS-TP layer network.
> 
> I have a strong opinion that both the MPLS-TP Identifiers and the MPLS-TP
> OAM Framework must use the same term (and definition) to identify the same
> entity.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Dec 2010 14:20:17 -0000

I agree with Italo (try not to gasp so loudly :-)

The I-Ds do appear to use the term consistently, and bringing this important
term to the front so it is really noticed seems important. Also adding it to the
Rosetta Stone I-D in a consistent way.

A *separate* issue is determining whether we are happy with the definition being
used. "interface" is a wriggly term with a long history in the IETF. Those
wanting to pick up some background could do worse than read IF-MIB (RFC2863) and
then look at the information about the use of "interfaces" in Section 8 of RFC
3813.

In RFC 4397 we worked with experts in ITU-T SG15 and got a bit anal about the
definitions. Section 3.6 discusses "link interfaces", and it would be nice to
stay consistent.

The question of "layers" is delicate, and should probably include "sub-layers".
But note that the interface is not the layer (which seems to be what Sasha is
objecting to), it is the "gateway" to the layer. One might think of it in terms
of adaptation functions, and indeed, I think this *is* consistent with the
current MPLS data plane architecture. Consider, for example, that an LSP end may
be represented as a virtual interface (i.e. the LSP is a virtual link).

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> BUSI, ITALO (ITALO)
> Sent: 10 December 2010 12:07
> To: Alexander Vainshtein; [email-masked]; [email-masked]
> Subject: [mpls] R: [mpls-tp] Use of term "interface" in MPLS-TP Identifiers
and
> The change #2 I am proposing is just aimed at clarifying that the server
MPLS-TP
> tunnel is a server sub-layer and not a server layer as per past discussion.
> 
> Italo
> 
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: maarten vissers <[email-masked]>
Date: Fri, 10 Dec 2010 14:33:08 +0000

Sasha,

The text in section 3 of RFC 5331 defines the concept of context-specific label spaces

   RFC 3031 describes per-platform and per-interface label spaces. This
   document introduces the more general concept of a "Context-Specific
   Label Space".  An LSR may maintain one or more context-specific label
   spaces.

The text in this section 3 lists a couple of context-specific label space examples and ends with the following notion:

   There may be other sorts of contexts as well.  For instance, we
   define the notion of an MPLS label being used to establish a context,
   i.e., identify a label space.  A "context label" is one that
   identifies a label table in which the label immediately below the
   context label should be looked up.

RFC 5331 is as such open to other context-specific label spaces.

An example of such other context-specific label space is a MPLS-TP Section and a MPLS-TP transport-LSP. Other examples could be Working and Protection SPME-LSPs.

I can't find in this specification of context-specific label space that each such label space must support ~1M label entries. This would be a complete overkill. In most cases 256, 512, 1024, 2048 or 4096 entries would be more than enough.

A system with e.g. 16 Section label spaces, each such label space supporting 512 transport-LSPs, 512 transport-LSP label spaces, each such label space supporting 511 service-LSP/PW/(H)VPLS entries can be supported by a single ~1M label table.

Regards,
Maarten

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexander Vainshtein
> Sent: 10 December 2010 08:01
> To: [email-masked]; Greg Mirsky
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] 答复: Looking for alternative term for per-
> interface MIP
> 
> Steven, Greg and all,
> 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".
> 
> over a Section (after publication of RFC 5960) is just one more example
> of such a 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.
> 
> 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.
> 
> - 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.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 10 Dec 2010 19:34:58 +0200

Adrian,
I agree with you that "interface" has a long history in the IETF and is not always used consistently.

My concern is about the term "per-interface label space" as it appears in 3031 and the consequent IETF documents.

Does your email imply that, from your point of view,  per-interface label space includes label space per terminated tunnel?
And that, as a consequence, processing of an incoming downstream-allocated label may depend on the label (or labels) that have been present in the label stack above it and have been popped?

I'd like to quote from Section 3.9 of RFC 3031 just to make sure we are all on the same page:   

   Although, as we shall see, MPLS supports a hierarchy, the processing
   of a labeled packet is completely independent of the level of
   hierarchy.  The processing is always based on the top label, without
   regard for the possibility that some number of other labels may have
   been "above it" in the past, or that some number of other labels may
   be below it at present.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adrian Farrel [[email-masked]]
Sent: Friday, December 10, 2010 4:20 PM
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] R: Use of term "interface" in MPLS-TP     Identifiers and OAM Framework drafts

Cheers,
Adrian

and
MPLS-TP

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 10 Dec 2010 10:32:49 -0800

Dear Sasha and All,
I agree with you that re-defining "interface" will confuse things more than
it will clarify. I think that it will be helpful to record implied
interpretation of "MPLS interface" in Rosetta Stone. In documents where use
of "interface" is ambiguous we can use, as much as possible, other terms. It
might be perhaps "virtual interface" or another term as well recorded in the
Rosetta Stone I-D.

Regards,
Greg

On Fri, Dec 10, 2010 at 9:34 AM, Alexander Vainshtein <
[email-masked]> wrote:

> Does your email imply that, from your point of view,  per-interface label
> space includes label space per terminated tunnel?
> And that, as a consequence, processing of an incoming downstream-allocated
> label may depend on the label (or labels) that have been present in the
> label stack above it and have been popped?
>
> Adrian Farrel [[email-masked]]
> > The OAM Framework and Identifier drafts are already using the term
> "interface"
> > in a consistent way among each other.
> >
> > According to the Identifiers draft the attachment point to a server
> MPLS-TP
> > Tunnel is an interface.
> >
> > > Subject: [mpls-tp] Use of term "interface" in MPLS-TP Identifiers and
> OAM
> > > Framework drafts
> > >
> > >
> > > I would therefore propose that the following definition is added to
> both
> > > drafts:
> > >
> > >  "
> > > I have a preference to keep the term "interface" on both drafts to
> speed
> > > up the work.
> > >
> > > Italo

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Dec 2010 20:12:44 -0000

Hi Sasha,

I don't think the fact that there was a label above in the stack is important.
What is important is whether the packet in hand has been received over an
interface (including a virtual interface) or not. An implementation and a
deployment should be free to choose whether an LSP tunnel is implemented as a
virtual interface or not. If it is not, the label in hand will be associated to
the interface over which the packet (with the previous label) was received. So,
in fact, no change in processing or semantics.

I think that some implementations do not support LSPs being presented as virtual
interfaces. This is fine and acceptable and within the scope of the
specifications. IIRC the MIB module allows an LSP tunnel to be configured either
way.

Adrian

> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: 10 December 2010 17:35
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] [mpls] R: Use of term "interface" in MPLS-TP
Identifiers
> and OAM Framework drafts
> 
> Adrian,
> I agree with you that "interface" has a long history in the IETF and is not
always
> used consistently.
> 
> My concern is about the term "per-interface label space" as it appears in 3031
and
> the consequent IETF documents.
> 
space
> includes label space per terminated tunnel?
> label may depend on the label (or labels) that have been present in the label
> stack above it and have been popped?
> 
> I'd like to quote from Section 3.9 of RFC 3031 just to make sure we are all on
the
> same page:
> Subject: Re: [mpls-tp] [mpls] R: Use of term "interface" in MPLS-TP
Identifiers
> and OAM Framework drafts
> https://www.ietf.org/mailman/listinfo/mpls-tp=