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

["BOCCI Matthew" <[e-mail]>]

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


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 04 November 2008 16:47
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
> Subject: Re: [Mpls-interop] draft-blb-mpls-tp-framework-01
> 
> 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:[e-mail]]
> Sent: Tuesday, November 04, 2008 18:09
> To: [e-mail]
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); 
> [e-mail]; 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.
> 
> 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
> 
> [e-mail] wrote:
> > 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:* [e-mail] 
> > [mailto:[e-mail]] *On Behalf Of 
> *Sprecher, Nurit 
> > (NSN - IL/Hod HaSharon)
> >
> >  
> >
> > 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.

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.

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

Please see my comment above.

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

Agreed. We will add this in the next version.

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

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.


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

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

If so, I agree.

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

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. 


> >
> > Best regards,
> >
> > Nurit
> >
> >  
> >
> >  
> >
> > 8.     
> >
> >  
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > Mpls-interop mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-interop
> >   
> 
> _______________________________________________
> Mpls-interop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-interop
> 
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop