Subject: Re: [mpls-tp] -03 of requirements draft & actions still to be resolved

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 22:28:58 +0000

Maarten,

On 30/01/2009 14:11, "Maarten Vissers" <[email-masked]> wrote:

>  
> Ben,
> 
> In the document you define
> 
> 1) segment as follows:
> 
> "Segment: The part of an LSP that traverses a single link or the part
>    of a PW that traverses a single link (i.e. that connects a pair of
>    adjacent {S|T}-PEs)."
> 
> In G.805 terminology, this "segment" would be called "link connection". Is
> this correct?
> If so, can you add to the document that a "segment" and a "link connection"
> are two terms for the same transport entity.

I believe you are correct. I have changed the definition to:

Segment: A link connection as defined in [G.805]. A segment is the part of
an LSP that traverses a single link or the part of a PW that traverses a
single link (i.e. that connects a pair of adjacent {S|T}-PEs).

> 2) concatenated segment as follows:
> 
> "Concatenated Segment: A contiguous part of an LSP or mult-segment PW
>    that comprises a set of segments in sequence."
> 
> In G.805 terminology, this "concatenated segment" would be called
> "serial-compound link connection". Is this correct? If so, can you add to
> the document that a "concatenated segment" and a "serial-compound link
> connection" are two terms for the same transport entity.

Neither G.805 nor G.800 define or use "serial compound" so I am not sure
what it means.

> If correct, then the definition of concatenated segment is not complete. It
> should include besides the "link connections/segments" also the "matrix
> connections" (or more general the "subnetwork connections") which
> interconnect two "link connections/segments" in equipment.

I believe you are correct. I have changed the definition to:

Concatenated Segment: A contiguous part of an LSP or mult-segment PW that
comprises a set of segments and their interconnecting nodes in sequence.

> 3) tandem connection as follows:
> 
> "Tandem Connection: A tandem connection is an arbitrary part of a
>    transport path that can be monitored (via OAM) independently from the
>    end-to-end monitoring (OAM).  It may be a segment, a concatenated
>    segment or any other ordered sequence of contiguous links and/or
>    segments of a transport path."
> 
> The term "links" should not appear in the definition of tandem connection as
> a link is a topological component and not a transport entity (tandem
> connection is one of the transport entities). It could perhaps be simpler to
> state that a Tandem Connection is a Monitored Concatenated Segment (or
> Monitored Serial-Compound Link Connection or Monitored SubNetwork
> Connection).
> 
> In addition, a tandem connection includes besides link connections/segments
> also matrix connections/subnetwork connections. If you do not define tandem
> connection as a monitored "XXX connection", then it is important to include
> the matrix connections as an element within a tandem connection.

I have changed the definition to:

Tandem Connection: A tandem connection is an arbitrary part of a transport
path that can be monitored (via OAM) independently from the end-to-end
monitoring (OAM). It may be a monitored segment, a monitored concatenated
segment or any other monitored ordered sequence of contiguous hops and/or
segments (and their interconnecting nodes) of a transport path.

> 4) domain as follows:
> 
> "   Domain: A domain represents a collection of entities (for example
>    network elements) that are grouped for a particular purpose, examples
>    of which are administrative and/or managerial responsibilities, trust
>    relationships, addressing schemes, infrastructure capabilities,
>    survivability techniques, distributions of control functionality,
>    etc.  Examples of such domains include IGP areas and Autonomous
>    Systems."
> 
> Another example of domain based grouping is access domains between
> T-PE/NTU/MTU nodes and first office with S-PE, metro domains between
> successive S-PEs located at metro edge (connecting to access domain) and
> metro core (connecting to core domain) and core domains between successive
> S-PEs located at metro core locations. These domains are characterized by
> their tunnels (MPLS-TP Path layer connections); those tunnels terminate at
> the domain edges. I propose to add a few words to include those tunnel
> connection based domains.

As mentioned by Adrian, I don't think we have to give an exhaustive list of
examples.

BTW Adrian, the definition is based on that in RFC 4726 and RFC 4655.

Ben

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

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Feb 2009 11:14:46 +0100

Ben,

Thanks for making those changes.

With respect to serial-compound link in G.805 you find it introduced/defined
in clause 5.3.2.2/G.805. It has been copied from clause 6.2.6/G.852.2.

With respect to listing of domain examples, I would like to point you to the
use of the term "aggregation domains" in section 1.2. This is the only type
of "domain" that you find referred to in the draft, and it is the domain
type that is not listed as example in the definition of domain. In my
opinion it would be better that the list of examples include at least the
domain types referred to in the document itself.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: maandag 2 februari 2009 23:29
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to be
resolved

Maarten,

On 30/01/2009 14:11, "Maarten Vissers" <[email-masked]> wrote:

> In G.805 terminology, this "segment" would be called "link 
> connection". Is this correct?

> "serial-compound link connection". Is this correct? If so, can you add 
> to the document that a "concatenated segment" and a "serial-compound 
> link connection" are two terms for the same transport entity.

> If correct, then the definition of concatenated segment is not 
> complete. It should include besides the "link connections/segments" 
> also the "matrix connections" (or more general the "subnetwork 
> connections") which interconnect two "link connections/segments" in
equipment.

> The term "links" should not appear in the definition of tandem 
> connection as a link is a topological component and not a transport 
> entity (tandem connection is one of the transport entities). It could 
> perhaps be simpler to state that a Tandem Connection is a Monitored 
> Concatenated Segment (or Monitored Serial-Compound Link Connection or 
> Monitored SubNetwork Connection).
> 
> In addition, a tandem connection includes besides link 
> connections/segments also matrix connections/subnetwork connections. 
> If you do not define tandem connection as a monitored "XXX 
> connection", then it is important to include the matrix connections as an
element within a tandem connection.

> successive S-PEs located at metro edge (connecting to access domain) 
> and metro core (connecting to core domain) and core domains between 
> successive S-PEs located at metro core locations. These domains are 
> characterized by their tunnels (MPLS-TP Path layer connections); those 
> tunnels terminate at the domain edges. I propose to add a few words to 
> include those tunnel connection based domains.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 21:14:36 +0000

Maarten,

> in clause 5.3.2.2/G.805. It has been copied from clause 6.2.6/G.852.2.

Ah OK. I have included a reference to serial-compound link connection as
part of the definition of concatenated segment.

> domain types referred to in the document itself.

That is a fair and reasonable point. I have added aggregation to the list of
examples so the definition now reads:

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 21:15:37 +0000

The definition now reads

Domain: A domain represents a collection of entities (for example network
elements) that are grouped for a particular purpose, examples of which are
administrative and/or managerial responsibilities, trust relationships,
addressing schemes, infrastructure capabilities, aggregation, survivability
techniques, distributions of control functionality, etc. Examples of such
domains include IGP areas and Autonomous Systems.