Re: [Mpls-interop] comment on framework documents

["Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>]

George,
I think you meant to 1:n, one TC for N LSPs isn't it?
Best regards,
Nurit

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of ext George Swallow
Sent: Tuesday, November 18, 2008 22:54
To: BUSI ITALO; Lou Berger; MEAD team
Subject: Re: [Mpls-interop] comment on framework documents

Italo -

Why do you limit this to 1:1?  Certainly 1:1 is permitted, but why not
N:1
as well?

...George


On 11/18/08 3:48 PM, "BUSI ITALO" <[e-mail]> wrote:

> Lou,
> 
> Thanks for commenting. I almost agree with you.
> 
> See my comments in line marked with [ib]
> 
> Italo 
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Lou Berger
>> Sent: Tuesday, November 18, 2008 2:49 PM
>> To: MEAD team
>> Subject: [Mpls-interop] comment on framework documents
>> 
>> So this is a comment that spans:
>>     draft-blb-mpls-tp-framework-01
>>     draft-busi-mpls-tp-oam-framework-00
>>     draft-sprecher-mpls-tp-survive-fwk-00.txt
>> 
>> and is directed to all the authors of those documents (and whoever
>> else feels like responding.)
>> 
>> Item 1: Hierarchy required to support LSP Tandem Connection
monitoring
>> 
>> As I read the requirements, the monitoring of an LSP segment (a.k.a,
>> MPLS-TP LSP Tandem Connection) requires the
>> establishment of MEPs at
>> the end-points of the LSP segment.  This in turn requires the use of
>> an additional label between the MEPs, i.e., LSP hierarchy.
>> 
>> I believe this is a correct description of the data plane impact of
>> LSP segment/Tandem Connection monitoring.  Does anyone disagree?
>> 
> 
> [ib] I agree. I think that we just need to clarify that there is a 1:1
> relationship between the two LSPs.
> 
>> * Presuming I didn't get it wrong, I think the use of hierarchy in
>> support of monitoring needs to be reflected in the MPLS-TP and OAM
>> framework documents. *
>> 
> 
> [ib] We have some description about that in the OAM framework and an
> open issue about whether this solution construct needs to be described
> within the OAM framework.
> I understand you think it should.
> Do you think we need to spell this out more explicitly?
> 
>> Item 2: Hierarchy required on protected LSP tandem connection
>> 
>> The requirements (req#46)state that OAM must be used (and not control
>> plane) to signal protection, and that recovery reference points are
>> defined at the same location as the OAM MEPs.
>> 
>> When combined with item 1, this means that hierarchy must be used on
>> the *working* path of a protected LSP segment.  Does anyone disagree?
>> 
> 
> [ib] I agree. I think this is required also for the *protection* LSP
> segment.
> 
>> * Presuming I didn't get it wrong, I think the use of hierarchy **on
>> the working path*** in support of monitoring needs to be reflected in
>> the MPLS-TP Survivability document. *
>> 
> 
> [ib] I agree that the survivability framework should reflect this.
> 
>> 
>> Any comments or objections?
>> 
>> Thanks,
>> Lou
>> 
>> _______________________________________________
>> 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
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop