Subject: [Mpls-interop] draft-blb-mpls-tp-framework-01

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 3 Nov 2008 20:39:50 +0100

Hi,

Looking at the MPLS-TP framework, I have some comments, questions, as
follows:

1.    There is a section on OAM. I would expect to refer from this
document to the MPLS-TP OAM framework and not to re-define or summarize
the other draft.

2.    The same holds for survivability (and I guess also for NMS).
Please remove the section and just refer to the survivability framework
document. 

3.    I would expect to find a section defining the TC (Tandem
Connection) architectural functional element that allows us to monitor,
manage and protect a segment of LSP or one-or-more segments of PWs. This
is a fundamental architectural functional element in MPLS-TP.

4.    In section 3.2 the OAM mechanisms are discussed "Section RFC 4379
[23]and BFD for MPLS LSPs [24] have defined alert mechanisms that enable
a MPLS LSR to identify and process MPLS OAM packets when the OAM packets
are encapsulated in an IP header.  These alert mechanisms are based on
TTL expiration and/or use an IP destination address in the range 127/8.
These mechanisms are the default mechanisms for MPLS networks in general
for identifying MPLS OAM   packets when the OAM packets are encapsulated
in an IP header. MPLS-TP must not rely on these mechanisms, and thus
relies on the GACH/GAL to demultiplex OAM packets." This looks relating
more to the analysis/solution document and not to the framework.

5.    It is written that the GE-ACH can be used for OAM, and APS, SCC,
MCC or other packet types in band over LSPs or PWs. I think the only
thing we agreed to define right now is channels for OAM functions. We
need to ensure that other channels can e defined as well. For example,
when we define a protocol for synchronizing protection state between
peers (what you call APS) we need to define a channel for this, the same
for other functions like signaling, management, etc. I would take these
examples out of section 3.4.2 as well. We need to identify control
packets. 

6.    If section 3.6 is included in this document it needs to indicate
that there is a need for static provisioning of protection entities, OAM
entities, etc. 

7.    Regarding bi-directional LSPs, it is important to indicate that
they should be co-routed and that the nodes need to be aware of the
relationship between both directions (this is needed for example in
order to generate OAM AIS messages). This has a clear impact for example
that if we refer to a control plane, than GMPLS should be used.  

Best regards,

Nurit

8.     

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

---

From: <[email-masked]>
Date: Tue, 4 Nov 2008 17:01:04 +0100

Hi Nurit.
 
I'm confused about your issue #5. The draft on Generic Associated
Channels -- that you agreed on accepting as WG item -- says:
   OAM functions and packets should be
   understood in the broad sense, that is, as a set of FCAPS mechanisms
   that also include Automatic Protection Switching (APS), Signalling
   Control Channel (SCC) and Management Control Channel (MCC)
 
As suggested by the name, the idea is to define a *generic* channel to
be used by required mechanisms, included in the examples or beyond, and
thus avoid to build a per application bearer. Why would we restrict it
to OAM only? AFAIU, this is aimed at carrying various kind of
communication, not an active mechanism by itself.
 
Regards,
 
Julien

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)

Hi,

Best regards,

Nurit

8.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 04 Nov 2008 16:08:43 +0000

I assume that Nurit was concerned that this text would in effect direct the
designers of APS etc to use this mechanism.

The uses of the ACH for protocols other OAM was only included by
way of examples and we can modify the text to make it less
prescriptive without loosing any clarity.

Regards

Stewart

[email-masked] wrote:
> be used by required mechanisms, included in the examples or beyond, 
> and thus avoid to build a per application bearer. Why would we 
> restrict it to OAM only? AFAIU, this is aimed at carrying various kind 
> of communication, not an active mechanism by itself.
>  
> Regards,
>  
> Julien
>
> ------------------------------------------------------------------------
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Sprecher, Nurit 
> (NSN - IL/Hod HaSharon)
>
>  
>
> Hi,
>
> document to the MPLS-TP OAM framework and not to re-define or 
> summarize the other draft.
>
> *Please remove the section and just refer to the survivability 
> framework document*.
>
> 3.    I would expect to find a *section defining the TC (Tandem 
> Connection) architectural functional element* that allows us to 
> *monitor*, *manage* and *protect* a segment of LSP or one-or-more 
> segments of PWs. This is a *fundamental* architectural functional 
> element in MPLS-TP.
>
> 4.    In section 3.2 the OAM mechanisms are discussed "Section RFC 
> 4379 [23]and BFD for MPLS LSPs [24] have defined alert mechanisms that 
> enable a MPLS LSR to identify and process MPLS OAM packets when the 
> OAM packets are encapsulated in an IP header.  These alert mechanisms 
> are based on TTL expiration and/or use an IP destination address in 
> the range 127/8.  These mechanisms are the default mechanisms for MPLS 
> networks in general for identifying MPLS OAM   packets when the OAM 
> packets are encapsulated in an IP header. MPLS-TP must not rely on 
> these mechanisms, and thus relies on the GACH/GAL to demultiplex OAM 
> packets." This looks relating more to the analysis/solution document 
> and not to the framework.
>
> peers (what you call APS) we need to define a channel for this, the 
> same for other functions like signaling, management, etc. I would take 
> these examples out of section 3.4.2 as well. We need to identify 
> control packets.
>
> that there is a need for static provisioning of protection entities, 
> OAM entities, etc.
>
> order to generate OAM AIS messages). This has a clear impact for 
> example that if we refer to a control plane, than GMPLS should be used.  
>
> Best regards,
>
> Nurit
>
>  
>
>  
>
> 8.     
>
>  
>
> ------------------------------------------------------------------------
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 4 Nov 2008 17:47:15 +0100

Hi,
Right, Stewart. 
We should indicate that inband channels are used for control messages
that support the FCAPS mechanisms (fault, configuration, accounting,
performance and security). It may be that APS will be used to support
one of mechanism and it may that it is not. This is a solution. As long
as we did not define it we should not specify it. 
We need the channels for DP OAM (fault and performance) and by
specifying OAM we do not specify specific tool/function and this is OK. 
I think we should also have the capability to have inband channels for
other applications that may need it in the future and this should be
specified as well. 
To sum up, I think the architecture document should indicate that inband
channels are used for control messages that support the FCAPS
mechanisms. It may be used in the future for other mechanisms as well. 
Best regards,
Nurit

-----Original Message-----
From: ext Stewart Bryant [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2008 18:09
To: [email-masked]
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] draft-blb-mpls-tp-framework-01

I assume that Nurit was concerned that this text would in effect direct
the
designers of APS etc to use this mechanism.

Regards

Stewart

---

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 17 Nov 2008 22:11:45 +0100

Hi Nurit,

I'm OK with your suggestion to indicate that ACH channels are used for
control messages that support the FCAPS mechanisms and that they may be
used in the future for other mechanisms as well. However, we must still
make it clear that there are  some constraints on that e.g. these future
mechanisms must not include transport of user plane traffic, etc

Please see below for responses to your other comments.

Matthew

> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 04 November 2008 16:47
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
> We should indicate that inband channels are used for control 
> messages that support the FCAPS mechanisms (fault, 
> configuration, accounting, performance and security). It may 
> be that APS will be used to support one of mechanism and it 
> may that it is not. This is a solution. As long as we did not 
> define it we should not specify it. 
> We need the channels for DP OAM (fault and performance) and 
> by specifying OAM we do not specify specific tool/function 
> and this is OK. 
> I think we should also have the capability to have inband 
> channels for other applications that may need it in the 
> future and this should be specified as well. 
> To sum up, I think the architecture document should indicate 
> that inband channels are used for control messages that 
> support the FCAPS mechanisms. It may be used in the future 
> for other mechanisms as well. 
> Best regards,
> Nurit
> 
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); 
> [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> I assume that Nurit was concerned that this text would in 
> effect direct the designers of APS etc to use this mechanism.
> 
> The uses of the ACH for protocols other OAM was only included 
> by way of examples and we can modify the text to make it less 

There were a number of motivations for the TP framework draft. One was
of course to specify the architecture of MPLS-TP. The other is to give
an overview of the subset of existing MPLS and new MPLS-TP functions
that make up MPLS-TP. This is not intended to respecify anything in the
other framework drafts, but I do agree that it might be a bit of a
challenge to keep this draft in sync with the other drafts.

> > *Please remove the section and just refer to the survivability 

Please see my comment above.

> > segments of PWs. This is a *fundamental* architectural functional 

Agreed. We will add this in the next version.

> > and not to the framework.

The GACH/GAL, and the addressing scheme and use (or not) of IP in
forwarding, demuliplexing OAM, etc is in my opinion quite fundamental to
the architecture of MPLS-TP, and not just a solution.

> > that there is a need for static provisioning of protection 

Do you mean as opposed to or in addition to control plane or based on
some sort of discovery mechanism?

If so, I agree.

> > example that if we refer to a control plane, than GMPLS should be

That's what we meant by "congruent", but I can see that this could be
interpreted as simply say that the forward and reverse directions must
traverse the same nodes, without actually implying an associated bethwee
forward and reverse directions of the LSP or PW at those nodes. I agree
we should add a clarification of this.

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 18 Nov 2008 00:03:55 +0100

Nurit,

please note that the oam-tp reqs incorporate:
    As part of the design of OAM mechanisms for MPLS-TP, a mechanism that
    enables the realization of a channel for general purpose signalling,
    e.g. for control, management and OAM information, associated with the
    data plane paths, MUST be provided. Such mechanism SHOULD support the
    operation of existing IP/MPLS OAM.

and
    the OAM mechanisms developed in support of the identified
    requirements SHALL be extensible and thus SHALL NOT preclude
    the definition of additional OAM functions in the future.

regards,
-m