Subject: Re: [mpls-tp] Addressing (my personal favorite topic)

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 11:19:22 +0100

I believe that it is important to realize that there are distinct items that
need to have "identifiers". Some of those items need identifiers only in the
management plane, others need identifiers only in the control plane, but
there are many that need identifiers in more then one plane; e.g. in data
plane and in management plane.
 
MPLS-TP will need multiple addressing/identification schemes in my
understanding. E.g.:
- addressing/identification scheme to reach management agents located in
management systems and network elements which are located at the
input/output ports of management channels
- addressing/identification scheme to reach control plane "agents" located
in network elements and management systems which are located at the
input/output ports of signalling channels
- addressing/identification scheme to identify the "Access Points" in
(admin) layer networks and sublayers; I.e. the "Access Point Identifiers" in
the management plane and the physical station/subrack/card/etc identifier in
the data plane
- identification scheme to identify each n-port transport entity (e.g.
2-port connection, n-port VLAN) in the management plane and in the data
plane
- identification scheme to identify each maintenance entity group level in a
transport entity in both the management plane and data plane
- addressing/identification scheme (e.g. EUI-48) to identify "physical
subsystems" in the data plane
- addressing/identification scheme to identify MEP and MIP functions
- addressing/identification scheme to identify input/output ports on a
transport entity; e.g. re-use EUI-48 of physical subsystem hosting in/ouput
port.
 
Many UNI-N and NNI port cards in MPLS-TP will already have one or more
EUI-48 idnetifiers (to support the Ethernet functionality (e.g. 802.3 PHY,
VPLS) on those ports). Those EUI-48 identifiers are reused in the data plane
to identify client and OAM input/output ports on mp2mp and rmp transport
entities (VLANs/VPLS instances). These EUI-48 identifiers may also be reused
in the data plane to identify client and OAM input/output ports on p2p and
p2mp transport entities (MS-PW, Path LSP, Section LSP).
 
Access Point Identifiers should follow the API definitions in transport
networks, e.g. OTN (refer to clause 15.2/G.709).
 
Maintenance Entity Group identifiers for mp2mp and rmp transport service
layer transport entities will follow the Y.1731 specified MEG ID format
(refer to annex A/Y.1731). For consistency in network management, it is
advantages to re-use this MEG ID also in p2p and p2mp transport service,
transport path and p2p transmission media section layer transport entities.
 
Management and control planes will need to use OSI and IP addresses to
identify the agents at the input/output ports of the management and
signalling communication channels.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: woensdag 28 januari 2009 7:21
To: Eric Gray; [email-masked]
Subject: Re: [mpls-tp] Addressing (my personal favorite topic)

Eric and all,
I have been speaking about the need of an addressing scheme both in
face-to-face meetings in Dublin (I did not attend the Minneapolis IETF) and
in some emails. I've also tried to convince the people that addressing is
required not just for network management but also for some OAM functions
(e.g., the misconnection detection), and that maintaining multiple
addressing schemes (with the necessary translations involved) would be
sub-optimal (to put it very mildly).
 
The only responses I've seen so far have been from Maarten (who suggested to
use the OSI addressing in network management for compatibility with legacy
equipment) and Stewart's responses to the contrary.
What I have NOT seen is clear perception of the need for an addressing
scheme for MPLS-TP at the conceptual/architectural level. I see Eric's
message as an indication that this is not just because I've missed some fine
text in the latest MPLS-TP drafts.
 
IMHO the big question is, how are we going to address the MPLS-TP addressing
scheme (or, actually, lack of an addressing scheme for MPLS-TP)  problem.
 
Regards,
     Sasha

  _____  

From: [email-masked] [[email-masked]] On Behalf Of Eric
Gray [[email-masked]]
Sent: Tuesday, January 27, 2009 9:55 PM
To: [email-masked]
Subject: [mpls-tp] Addressing (my personal favorite topic)

On several occasions, the issue of required and default addressing has been
raised.
 
In the latest round of design team meetings, several people pointed out that
a management
channel (as a practical consideration, at least) require addresses.
 
One thing I anticipate as a comment is what addressing scheme is the
default.  I expect
that we all know that the answer to that question is IP addressing, but I do
not feel that 
the NM requirements draft is the appropriate place to make such a statement
- except as
a potential qualification of multiple choices offered in some other
document.
 
The question is: what document is the natural home for a statement on
addressing, both
required and default?
 
I looked in the MPLS-TP requirements draft, and did not find it there.
Where else might it
be found?  Given the number of times this issue has been raised, I am sure
it should be
somewhere.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Tue, 3 Feb 2009 10:50:43 +0100

Hi all, sorry for interrupting.

Maarten, you state: "Management and control planes will need to use OSI
and IP addresses", which I find both rough and unsupported. First, I
think "or" instead of "and" would be enough. Then, to get back to the
roots of the discussion and without questioning the beauty of the OSI
technology and its unquestionable advantages, my carrier's requirements
express as "management and control MUST support IP addressing". You can
advocate that this is a sub-optimal solution, but please, spare me
deploying and maintaining an OSI network just to manage your MPLS-TP
boxes...

Regards,

Julien

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers

I believe that it is important to realize that there are distinct items
that need to have "identifiers". Some of those items need identifiers
only in the management plane, others need identifiers only in the
control plane, but there are many that need identifiers in more then one
plane; e.g. in data plane and in management plane.
 
MPLS-TP will need multiple addressing/identification schemes in my
understanding. E.g.:
- addressing/identification scheme to reach management agents located in
management systems and network elements which are located at the
input/output ports of management channels
- addressing/identification scheme to reach control plane "agents"
located in network elements and management systems which are located at
the input/output ports of signalling channels
- addressing/identification scheme to identify the "Access Points" in
(admin) layer networks and sublayers; I.e. the "Access Point
Identifiers" in the management plane and the physical
station/subrack/card/etc identifier in the data plane
- identification scheme to identify each n-port transport entity (e.g.
2-port connection, n-port VLAN) in the management plane and in the data
plane
- identification scheme to identify each maintenance entity group level
in a transport entity in both the management plane and data plane
- addressing/identification scheme (e.g. EUI-48) to identify "physical
subsystems" in the data plane
- addressing/identification scheme to identify MEP and MIP functions
- addressing/identification scheme to identify input/output ports on a
transport entity; e.g. re-use EUI-48 of physical subsystem hosting
in/ouput port.
 
Many UNI-N and NNI port cards in MPLS-TP will already have one or more
EUI-48 idnetifiers (to support the Ethernet functionality (e.g. 802.3
PHY, VPLS) on those ports). Those EUI-48 identifiers are reused in the
data plane to identify client and OAM input/output ports on mp2mp and
rmp transport entities (VLANs/VPLS instances). These EUI-48 identifiers
may also be reused in the data plane to identify client and OAM
input/output ports on p2p and p2mp transport entities (MS-PW, Path LSP,
Section LSP).

transport path and p2p transmission media section layer transport
entities.

Regards,
Maarten

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexander Vainshtein

Eric and all,
I have been speaking about the need of an addressing scheme both in
face-to-face meetings in Dublin (I did not attend the Minneapolis IETF)
and in some emails. I've also tried to convince the people that
addressing is required not just for network management but also for some
OAM functions (e.g., the misconnection detection), and that maintaining
multiple addressing schemes (with the necessary translations involved)
would be sub-optimal (to put it very mildly).
 
The only responses I've seen so far have been from Maarten (who
suggested to use the OSI addressing in network management for
compatibility with legacy equipment) and Stewart's responses to the
contrary.
What I have NOT seen is clear perception of the need for an addressing
scheme for MPLS-TP at the conceptual/architectural level. I see Eric's
message as an indication that this is not just because I've missed some
fine text in the latest MPLS-TP drafts.
 
IMHO the big question is, how are we going to address the MPLS-TP
addressing scheme (or, actually, lack of an addressing scheme for
MPLS-TP)  problem.
 
Regards,
     Sasha

________________________________

From: [email-masked] [[email-masked]] On Behalf Of
Eric Gray [[email-masked]]

On several occasions, the issue of required and default addressing has
been raised.
 
In the latest round of design team meetings, several people pointed out
that a management
channel (as a practical consideration, at least) require addresses.
 
One thing I anticipate as a comment is what addressing scheme is the
default.  I expect
that we all know that the answer to that question is IP addressing, but
I do not feel that 
the NM requirements draft is the appropriate place to make such a
statement - except as
a potential qualification of multiple choices offered in some other
document.

I looked in the MPLS-TP requirements draft, and did not find it there.
Where else might it
be found?  Given the number of times this issue has been raised, I am
sure it should be
somewhere.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Feb 2009 15:40:32 +0100

Julien,

If all carriers agree that MPLS-TP management and control must support IP
addressing only, it is possible to delete support for OSI addressing.
 
Until that time, equipment will have to support both addressing schemes and
operators can select one of these two; in your case IP addressing. 

>From an equipment vendors perspective there is as such an "and" and from an
operators perspective there is an "or".

But it would be great if equipment could just support IP addressing only...

Regards,
Maarten

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: dinsdag 3 februari 2009 10:51
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [mpls-tp] Addressing (my personal favorite topic)

Maarten, you state: "Management and control planes will need to use OSI and
IP addresses", which I find both rough and unsupported. First, I think "or"
instead of "and" would be enough. Then, to get back to the roots of the
discussion and without questioning the beauty of the OSI technology and its
unquestionable advantages, my carrier's requirements express as "management
and control MUST support IP addressing". You can advocate that this is a
sub-optimal solution, but please, spare me deploying and maintaining an OSI
network just to manage your MPLS-TP boxes...

Regards,

Julien

Of Maarten Vissers

located in network elements and management systems which are located at the

 

Regards,
Maarten

Eric and all,

IMHO the big question is, how are we going to address the MPLS-TP addressing
scheme (or, actually, lack of an addressing scheme for
MPLS-TP)  problem.
 
Regards,
     Sasha

 
In the latest round of design team meetings, several people pointed out that
a management channel (as a practical consideration, at least) require
addresses.
 
One thing I anticipate as a comment is what addressing scheme is the
default.  I expect that we all know that the answer to that question is IP
addressing, but I do not feel that the NM requirements draft is the
appropriate place to make such a statement - except as a potential
qualification of multiple choices offered in some other document.
 
The question is: what document is the natural home for a statement on
addressing, both required and default?
 
it should be somewhere.

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 3 Feb 2009 10:49:07 -0500

Hi all,

This is a discussion we had many times already. One needs to be very
specific on the application. 

OSI address - what specific OSI addresses are we discussing? All OSI
stacks use IP addressing somewhere around layer 4 as everyone is using
remote access over an IP communication network. The OSI address used at
the application level is not ever visible - and it is specific for the
application anyway. And API addresses are also for a specific
application. It's never required that each application needs to support
ALL other (today and future) applications' addresses for
interoperability of the applications. And in GMPLS, there is nothing
precluding one to use TL1 addresses or API or whatever for control plane
addressing, data plane addressing, or the signaling communications
network. Only for interoperability, it's required to support IP
addressing. I agree with Neil - many of the on-going discussions are
repeating discussions because of the lack of specifics - the devil is
always in the details as he says:-)

So what are the details? A control plane that's IP-based will use IP
addressing. A management plane will use the addresses of its specific
application. One doesn't expect TL1 to use Q3 addressing. RFC4139 has
very carefully worded statements to specify what is within scope and out
of scope on addressing which can be used here. Section 4.1 discusses
soft permanent connections (management plane used for end point
identification and a control plane within the domain). As it states, the
label association at the ingress and egress nodes is implementation
specific - it may be done at the node, at the EMS level, or the NMS
level.

"Management and control planes will need to use OSI and IP addresses" is
not specific - it will be interpreted to say that control planes MUST
support OSI addresses - which as Julien says, is a "not needed"
interoperability requirement and has costly implications for all
operators and vendors. The requirement should specifically say,
"Management planes will use OSI addresses. IP-based control planes MUST
support IP addresses. If interworking is required, the association is
implementation specific and outside the scope of this document." Note, I
didn't say "only" for IP addresses, so vendors wanting to support TL1 or
MAC addressing within their domain - good luck- just don't make it
visible to me for managing:-)

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Tuesday, February 03, 2009 9:41 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] Addressing (my personal favorite topic)

Julien,

If all carriers agree that MPLS-TP management and control must support
IP
addressing only, it is possible to delete support for OSI addressing.
 
Until that time, equipment will have to support both addressing schemes
and
operators can select one of these two; in your case IP addressing. 

But it would be great if equipment could just support IP addressing
only...

Regards,
Maarten

-----Original Message-----

Maarten, you state: "Management and control planes will need to use OSI
and
IP addresses", which I find both rough and unsupported. First, I think
"or"
instead of "and" would be enough. Then, to get back to the roots of the
discussion and without questioning the beauty of the OSI technology and
its
unquestionable advantages, my carrier's requirements express as
"management
and control MUST support IP addressing". You can advocate that this is a
sub-optimal solution, but please, spare me deploying and maintaining an
OSI
network just to manage your MPLS-TP boxes...

Regards,

Julien

Behalf
Of Maarten Vissers

I believe that it is important to realize that there are distinct items
that
need to have "identifiers". Some of those items need identifiers only in
the
management plane, others need identifiers only in the control plane, but
there are many that need identifiers in more then one plane; e.g. in
data
plane and in management plane.
 
the
Identifiers" in
the management plane and the physical station/subrack/card/etc
identifier in
in a
in/ouput
port.
 
Many UNI-N and NNI port cards in MPLS-TP will already have one or more
EUI-48 idnetifiers (to support the Ethernet functionality (e.g. 802.3
PHY,
VPLS) on those ports). Those EUI-48 identifiers are reused in the data
plane
to identify client and OAM input/output ports on mp2mp and rmp transport
entities (VLANs/VPLS instances). These EUI-48 identifiers may also be
reused
in the data plane to identify client and OAM input/output ports on p2p
and
p2mp transport entities (MS-PW, Path LSP, Section LSP).

 
 
Regards,
Maarten

Behalf
Of Alexander Vainshtein

Eric and all,
and
in some emails. I've also tried to convince the people that addressing
is
 
suggested to
use the OSI addressing in network management for compatibility with
legacy
fine
 
addressing
 
Regards,
     Sasha

Eric

been
raised.
 
that
 
default.  I expect that we all know that the answer to that question is
IP

sure
it should be somewhere.