Subject: [Mpls-interop] Overview v10 and meeting notes uploaded

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 7 Apr 2008 08:09:07 -0400

All, version 10 of the overview has been uploaded with the following
changes from v9:

- added control plane architecture diagrams - with fix
-  replaced Vach's ring protection w/ Matthew's (same concepts,
prettier)
-  added LFU clarification
- added MSP-ring slides
- OAM update
-  updated recommendation/summary section

The meeting notes form the Control Plane and Network Management team
calls have also been uploaded all can be found via the following link:
http://ties.itu.int/ftp/public/itu-t/ahtmpls/readandwrite/doc_exchange/

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Apr 2008 14:17:27 +0100

A couple of comments:

1) It would be nice to retain the name of the individual contributors in 
some form, rather than just listing their companies.

2) Slide 7  - "no LSP path merge" if strictly interpreted this is quite 
restrictive in the design. Is this really the requirement or is it 
really a simplification of a more complex problem - adequate resources + 
trail to trail disambiguation etc.? This may not be the time/place to 
discuss, but we should understand this at some time.

Stewart

---

From: Loa Andersson <[email-masked]>
Date: Mon, 07 Apr 2008 15:51:52 +0200

Stewart Bryant wrote:
> 2) Slide 7  - "no LSP path merge" 

actually that requirement is *extremely* ambigious. If you expand
the acronym you get "label switching path path merge", does that
mean that no two LSPs may follow the same path?  I hope not.
Or does it mean that you can't carry LSPs within a tunnel? I hope not.

I guess that the requirement that is indicated is:
"no merge of LSPs in such a way that the switching context is lost",
but with that reformulation Stewarts comments still is valid.

/Loa

if strictly interpreted this is quite

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 7 Apr 2008 10:06:50 -0400

The statement "no LSP path merge" is an implementation restriction not a
requirement.  Perhaps we could rephrase as a main bullet and a sub
bullet:

Maintain identification of individual LSPs
 - Unambiguous identification of the LSP source and the association
between the data and OAM within the LSP

Not sure how the above can be met if the LSP merges with another LSP
(e.g. PHP more than one LSP on a link).

Malcolm Betts
Nortel Networks

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Monday, April 07, 2008 9:52 AM
> To: [email-masked]
> Cc: Betts, Malcolm (CAR:X632); [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Mpls-interop] Overview v10 and meeting notes uploaded
> 
> 
> 
> Stewart Bryant wrote:
> > A couple of comments:
> > 
> > 1) It would be nice to retain the name of the individual 
> contributors 
> > in some form, rather than just listing their companies.
> > 
> actually that requirement is *extremely* ambigious. If you 
> expand the acronym you get "label switching path path merge", 
> does that mean that no two LSPs may follow the same path?  I hope not.
> "no merge of LSPs in such a way that the switching context is 
> lost", but with that reformulation Stewarts comments still is valid.
> 
> 
> /Loa
> 
> > really a simplification of a more complex problem - 
> adequate resources 
> > + trail to trail disambiguation etc.? This may not be the 
> time/place 
> > to discuss, but we should understand this at some time.
> > 
> > Stewart
> > 
> >

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 7 Apr 2008 10:18:43 -0400

I am still confused by slide 49.
 
1)  Is it possible to run OAM between A and E in a) a PW or b) an LSP
 
2)  I assume that node C has back to back MEPs i.e one for A-C OAM and
another for C-E OAM.
 
3) If the answer to 1a) or 1b) is yes can node C support a MIP for the
A-E OAM

Malcolm Betts 
Nortel Networks 

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Betts, Malcolm
(CAR:X632)
	Sent: Monday, April 07, 2008 8:09 AM
	To: [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: [Mpls-interop] Overview v10 and meeting notes uploaded

	All, version 10 of the overview has been uploaded with the
following changes from v9: 

	The meeting notes form the Control Plane and Network Management
team calls have also been uploaded all can be found via the following
link:

http://ties.itu.int/ftp/public/itu-t/ahtmpls/readandwrite/doc_exchange/
<http://ties.itu.int/ftp/public/itu-t/ahtmpls/readandwrite/doc_exchange/

	Malcolm Betts 
	Nortel Networks 

	Confidentiality Notice:  This message and any attachments may
contain information that is privileged and confidential. If you have
reason to believe that you are not the intended recipient or a person
responsible for delivering this message to an intended recipient, you
are hereby notified that any review, dissemination, distribution, or
copying of this message is strictly prohibited. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.

---

From: "LASSERRE, Marc \(Marc\)" <[email-masked]>
Date: Mon, 7 Apr 2008 16:24:53 +0200

How about saying "No LSP merging (e.g. no use of LDP mp2p signaling in
order to avoid losing LSP head-end information)"?

Marc

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: lundi 7 avril 2008 15:17
To: Malcolm Betts
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Mpls-interop] Overview v10 and meeting notes uploaded

A couple of comments:

Stewart

---

From: David Ward <[email-masked]>
Date: Mon, 7 Apr 2008 09:28:48 -0500

Stewart -

On Apr 7, 2008, at 8:17 AM, Stewart Bryant wrote:

> contributors in

The list just got too long and unmanageable.

> discuss, but we should understand this at some time.

As discussed in Philly it was a simplification of a more complex  
problem. I think Marc's suggestion is the path forward ('snort). I'll  
adopt that wording.

-DWard

---

From: "Italo Busi" <[email-masked]>
Date: Mon, 7 Apr 2008 17:41:16 +0200

Marc,

I agree with your suggestion. I am just wondering whether we cannot make it more
generic like:

"no use of mp2p LSP in order to avoid losing LSP head-end information"

Italo

> [mailto:[email-masked]] On Behalf Of LASSERRE, 
> Marc (Marc)
> Sent: Monday, April 07, 2008 4:25 PM
> To: [email-masked]; Malcolm Betts

---

From: Mark Townsley <[email-masked]>
Date: Mon, 07 Apr 2008 18:23:50 +0200

> The list just got too long and unmanageable.
It's a bit of a cultural faux pas to highlight companies vs. individuals 
in the IETF. Expect more resistance along that which Stewart just exhibited.

- Mark

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 8 Apr 2008 09:58:45 -0400

Maarten, I agree with the comments from Martin, also see in line below
re AIS processing:

Malcolm Betts 
Nortel Networks 

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: Tuesday, April 08, 2008 5:09 AM
	To: Betts, Malcolm (CAR:X632); [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: RE: Overview v10 and meeting notes uploaded

	Malcolm, 
	 
	Some comments on the slides on OAM:
	 
	0) general: I am not sure how to interprete "PW" and "LSP" at
the moment... up to a month ago, a PW was a network service layer
connection, represented as a Channel layer connection in T-MPLS (C610,
June 2007) and a LSP was a network tunnel layer connection, represented
as a Path layer connection in T-MPLS (C610)... an LSP thus carried an
aggregate of PWs and VPLSs...
	- At this point, looking into -v10 slide set, I wonder if the
above undestanding is still correct. If so, then the PW OAM and LSP OAM
desciptions (see items 1 and 2) are not correct.  
	- If there has been a change in the definition/deployment of PW
and LSP terms, then we should start to refer to those as PW, PW-LSP
(i.e. PW TCM OAM level) and Tunnel-LSP (i.e. Tunnel end-to-end OAM level
or TCM OAM level).
	  Slides 17/18 then present the PW-LSP (i.e. per service
instance) MEG levels and functions. In this case, we can remove the
end-to-end PW MEG level, while this level duplicates the end-to-end
PW-LSP MEG level. Essentially, the PW degenerates to be just the
encapsulation process; the PW-LSPs are the true per service instance
connections... there would now be no longer a need for the PW label;
this task is now provided by the PW-LSP label
	 
	1) slide 17: I would have expected that the PE terminates the
MPLS Tunnel (T-MPLS Path) layer connection and switches the MPLS PW cq
VPLS (T-MPLS Channel cq Ethernet VLAN channel) connections. This implies
that the LSP (MPLS Tunnel) terminates in the intemediate PE; there is as
such a LSP in carrier 1, another LSP in carrier 2 and potentially
another LSP on the NNI between carriers 1 and 2. Each LSP is ending in a
MEP. The end-to-end PW OAM should have two MIPs in each of the two
intermediate PEs; this end-to-end PW OAM is the Service Provider's PW
MEG level OAM. Besides this SP MEP level OAM, the PW must have carrier 1
PW MEG level OAM and carrier 2 PW MEG level OAM with MEPs in the PEs at
the edges of each carrier's network. The segment LSP OAM MEG level must
be described as end-to-end LSP OAM.
	
	2) slide 18: similar to the previous item, the PEs terminate the
LSP (otherwise these nodes would be P nodes) and there is a LSP in
region 1, another LSP in region 2, potentially another LSP between
region 1 and 2, and a last LSP between carrier 1 and the attached PE.
This implies that the region segment LSP OAM level is the end-to-end LSP
OAM level. The end-to-end LSP OAM and the carrier LSP OAM levels are PW
OAM levels; specifically the end-to-end LSP OAM MEG level is the
end-to-end PW MEG level (i.e. the Service Provider PW MEG level), and
the carrier LSP OAM MEG level is the carrier PW MEG level. the
end-to-end PW OAM MEG level can be deleted; it doesn't exist.
	3) can you add a slide in which the AIS OAM (insertion,
extraction) is described for the network service/channel, network
tunnel/path and section layers. I am asking this as AIS insertion is
performed in the Physical Media-to-Section layer adaptation sink
function (Section-AIS), the Section-to-Path layer adaptation sink
function (Path-AIS) and Path-to-Channel layer adaptation sink function
(Channel-AIS). AIS extraction/detection is performed in the Section
layer termination sink function (Section-AIS), the Path layer
termination sink function (Path-AIS) and Channel layer termination sink
function (Channel-AIS). There is as such an asymmetry in the AIS
insertion/extraction that you do not find back in other OAM cases (with
the exception of LCK OAM).
	
	[Malcolm Betts]  I find the terminology that you are using to be
very confusing.  MPLS supports recursive encapsulation.  The "physical
media" may be a GFP encapsulation or Ethernet or...  We can abstract
this to be just the normal client/server AIS processing.  We do not need
to show the details of all client/server relationships in this overview
chart deck.
	 
	Regards,
	Maarten

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Malcolm Betts
	Sent: 07 April 2008 14:09
	To: [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Overview v10 and meeting notes uploaded

	Malcolm Betts 
	Nortel Networks

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 11 Apr 2008 15:48:47 +0200

Maarten,
 
I agree that some slides describing the AIS insertion process could be useful. 
 
However I do not think they are required for option 1/2 selection so we can
develop them later in the process.
 
I agree that TCM in already defined transport technologies has never introduced
further encapsulation. However I fail to see any architectural issue with it.
 
In my opinion this is allowed by G.805/G.806 atomic functions: the TCM creates a
sub-layer trail and the adaptation function (TMT/TM_A) can have a process
performing label push/pop operations.
 
I think that the implementation solution should not change the TCM concept nor
the architecture so the TCM is still a sub-layer within a single layer network.
This is in line with slide 34 (v13) that has identified the need for a mechanism
to bind the TCM label to the underlying LSP or PW being monitored.
 
Italo

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten
Vissers
Sent: Tuesday, April 08, 2008 5:36 PM
To: 'Malcolm Betts'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Overview v10 and meeting notes uploaded

Malcolm,
 
A single generic description of AIS insertion and extraction may be sufficient
in the overview chart deck. This to make everybody aware that AIS insertion is
required also if there is no other OAM processed in the interface port. E.g. in
a P node that does not provide Section OAM and does not provide Tunnel-LSP MIPs
or MEPs it is required to generate Tunnel-LSP AIS for all active tunnels when
there is a Loss of Signal condition (or another physical media related signal
fail condition); if such port is not able to generate AIS, alarm suppression
will only work partly.
 
Terminology: G.805 specifies that there is a Transmission Media layer network
which may contain a Section layer network and will contain a Physical Media
layer network. Like used in ATM, a Physical Media layer network may be an
abstraction of more than one layer network (e.g. ATM over HOVC/MSn/RSn/OSn).
 
Recursive encapsulation: So far TCM did not introduce further encapsulation in
the network, and TCM was a monitoring function within a connection. TCM so far
introduced monitoring sublayers, located within the layer network of the
connection. With the new approach using recursive encapsulation I wonder what
the layer network model should be. From a G.806 atomic function perspective it
is simply a sequence of adaptation and termination functions, but if we abstract
this into layer networks, should we present the Network Connection Monitoring
(NCM), Tandem Connection Monitoring (TCM) and possibly Link Connection
Monitoring (LCM) instances as separate MPLS layer networks, or as a single MPLS
layer network. I.e. will we create layer networks on the fly (when activating
TCM or LCM), or will there be just a single layer network with a special
implementation of TCM/LCM? Have you given this any consideration so far?
 
Regards,
Maarten
 
  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm
Betts
Sent: 08 April 2008 15:59
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Overview v10 and meeting notes uploaded

Maarten, I agree with the comments from Martin, also see in line below re AIS
processing:

Malcolm Betts 
Nortel Networks 

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to believe
that you are not the intended recipient or a person responsible for delivering
this message to an intended recipient, you are hereby notified that any review,
dissemination, distribution, or copying of this message is strictly prohibited.
If you have reason to believe that you are not the intended recipient or a
person responsible for delivering this message to an intended recipient, please
contact the sender immediately by reply email and destroy all copies of the
original message.

  _____  

Malcolm, 

0) general: I am not sure how to interprete "PW" and "LSP" at the moment... up
to a month ago, a PW was a network service layer connection, represented as a
Channel layer connection in T-MPLS (C610, June 2007) and a LSP was a network
tunnel layer connection, represented as a Path layer connection in T-MPLS
(C610)... an LSP thus carried an aggregate of PWs and VPLSs...
- At this point, looking into -v10 slide set, I wonder if the above undestanding
is still correct. If so, then the PW OAM and LSP OAM desciptions (see items 1
and 2) are not correct.  
- If there has been a change in the definition/deployment of PW and LSP terms,
then we should start to refer to those as PW, PW-LSP (i.e. PW TCM OAM level) and
Tunnel-LSP (i.e. Tunnel end-to-end OAM level or TCM OAM level).
  Slides 17/18 then present the PW-LSP (i.e. per service instance) MEG levels
and functions. In this case, we can remove the end-to-end PW MEG level, while
this level duplicates the end-to-end PW-LSP MEG level. Essentially, the PW
degenerates to be just the encapsulation process; the PW-LSPs are the true per
service instance connections... there would now be no longer a need for the PW
label; this task is now provided by the PW-LSP label
 
1) slide 17: I would have expected that the PE terminates the MPLS Tunnel
(T-MPLS Path) layer connection and switches the MPLS PW cq VPLS (T-MPLS Channel
cq Ethernet VLAN channel) connections. This implies that the LSP (MPLS Tunnel)
terminates in the intemediate PE; there is as such a LSP in carrier 1, another
LSP in carrier 2 and potentially another LSP on the NNI between carriers 1 and
2. Each LSP is ending in a MEP. The end-to-end PW OAM should have two MIPs in
each of the two intermediate PEs; this end-to-end PW OAM is the Service
Provider's PW MEG level OAM. Besides this SP MEP level OAM, the PW must have
carrier 1 PW MEG level OAM and carrier 2 PW MEG level OAM with MEPs in the PEs
at the edges of each carrier's network. The segment LSP OAM MEG level must be
described as end-to-end LSP OAM.

2) slide 18: similar to the previous item, the PEs terminate the LSP (otherwise
these nodes would be P nodes) and there is a LSP in region 1, another LSP in
region 2, potentially another LSP between region 1 and 2, and a last LSP between
carrier 1 and the attached PE. This implies that the region segment LSP OAM
level is the end-to-end LSP OAM level. The end-to-end LSP OAM and the carrier
LSP OAM levels are PW OAM levels; specifically the end-to-end LSP OAM MEG level
is the end-to-end PW MEG level (i.e. the Service Provider PW MEG level), and the
carrier LSP OAM MEG level is the carrier PW MEG level. the end-to-end PW OAM MEG
level can be deleted; it doesn't exist.
3) can you add a slide in which the AIS OAM (insertion, extraction) is described
for the network service/channel, network tunnel/path and section layers. I am
asking this as AIS insertion is performed in the Physical Media-to-Section layer
adaptation sink function (Section-AIS), the Section-to-Path layer adaptation
sink function (Path-AIS) and Path-to-Channel layer adaptation sink function
(Channel-AIS). AIS extraction/detection is performed in the Section layer
termination sink function (Section-AIS), the Path layer termination sink
function (Path-AIS) and Channel layer termination sink function (Channel-AIS).
There is as such an asymmetry in the AIS insertion/extraction that you do not
find back in other OAM cases (with the exception of LCK OAM).

[Malcolm Betts]  I find the terminology that you are using to be very confusing.
MPLS supports recursive encapsulation.  The "physical media" may be a GFP
encapsulation or Ethernet or...  We can abstract this to be just the normal
client/server AIS processing.  We do not need to show the details of all
client/server relationships in this overview chart deck.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm
Betts
Sent: 07 April 2008 14:09
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Overview v10 and meeting notes uploaded

All, version 10 of the overview has been uploaded with the following changes
from v9: 

- added control plane architecture diagrams - with fix 
-  replaced Vach's ring protection w/ Matthew's (same concepts, prettier) 
-  added LFU clarification 
- added MSP-ring slides 
- OAM update 
-  updated recommendation/summary section 

The meeting notes form the Control Plane and Network Management team calls have
also been uploaded all can be found via the following link:

 <http://ties.itu.int/ftp/public/itu-t/ahtmpls/readandwrite/doc_exchange/>
http://ties.itu.int/ftp/public/itu-t/ahtmpls/readandwrite/doc_exchange/ 

Malcolm Betts 
Nortel Networks 

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to believe
that you are not the intended recipient or a person responsible for delivering
this message to an intended recipient, you are hereby notified that any review,
dissemination, distribution, or copying of this message is strictly prohibited.
If you have reason to believe that you are not the intended recipient or a
person responsible for delivering this message to an intended recipient, please
contact the sender immediately by reply email and destroy all copies of the
original message.