Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

From: "[email-masked]" <[email-masked]>
Date: Thu, 28 Jul 2011 15:54:09 -0400

And propagate to the VC12 carried By the PW? 

Huivi

Verzonden van mijn HTC

----- Reply message -----
Van: "Sam Aldrin" <[email-masked]>
Aan: "Shah, Himanshu" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Rafi Ram" <[email-masked]>
Onderwerp: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
Datum: do, jul. 28, 2011 15:04

Also, if we were to propagate to Tp, why stop there? It should be propagated to PW as well, right?

Sam

Sent from my iPhone

On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu" <[email-masked]> wrote:

> I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made this exact point at the mike
> during presentation.
> 
> /himanshu
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
> Sent: Thursday, July 28, 2011 2:30 PM
> To: Daniel Cohn; Greg Mirsky
> Cc: Rafi Ram; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> 
> Hi,
> 
> I also don't believe SD is needed for MPLS-TP. Such defect is not related to MPLS-TP and should be handled in the server layer, such as changing the FEC type in OTN, etc.
> 
> Regards,
> Shahram
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
> Sent: Thursday, July 28, 2011 10:15 AM
> To: Greg Mirsky
> Cc: [email-masked]; [email-masked]; [email-masked]; Rafi Ram
> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> 
> True enough in general. But in this particular example, there is nothing suggested by this draft that requires huge implementation efforts or paradigm changes. So I fail to see why we should settle for less functionality than is available in existing transport networks.
> 
> DC
> 
> -----Original Message-----
> From: Greg Mirsky [mailto:[email-masked]]
> Sent: Thursday, July 28, 2011 1:00 PM
> To: Daniel Cohn
> Cc: Eric Osborne (eosborne); Rafi Ram; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
> Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> 
> Hi Daniel,
> I think that while we're building MPLS-TP to be suited for the
> transport we need to remember that it, as Neil pointed out on number
> of occasions, is not BOS layer and doesn't put bits on a wire. Thus it
> has characteristic that makes it different from other layers of a
> transport network and, I think, as result not all existing concepts of
> transport are applicable to packet layer realized by MPLS-TP.
> 
> Regards,
> Greg
> 
> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn <[email-masked]> wrote:
>> Hi Eric,
>> 
>> One of the reasons why we need SD in TP is because TP is supposed to
>> provide the same "look and feel" of existing transport networks, as
>> specified in the TP requirements document.
>> Transport networks technologies have long supported the distinction
>> between "degraded" and " faulty". In particular, protection technologies
>> in use have this distinction built into the innermost recedes of their
>> protocols.
>> Even in the TP requirements didn't spell this out, I think it would be a
>> mistake not to take advantage of years of experience in transport
>> networks OAM.
>> 
>> Regards,
>> 
>> Daniel
>> 
>> -----Original Message-----
>> From: Eric Osborne (eosborne) [mailto:[email-masked]]
>> Sent: Thursday, July 28, 2011 11:12 AM
>> To: Greg Mirsky; Daniel Cohn; Rafi Ram; [email-masked];
>> [email-masked]; [email-masked]; D'Alessandro Alessandro
>> Gerardo; [email-masked]
>> Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>> 
>> Hi Greg-
>> There is a difference between SF and SD.  Converting SD into Down
>> means that it will be interpreted exactly the same as SF, and if that's
>> the case why have SD at all?  If SD is necessary it must be somehow
>> different from SD.
>> 
>> All-
>> 
>> Having said that, I'm not sure I disagree with Greg.  It seems that
>> this idea of propagating server layer SD up into TP is being done
>> because there's no good way to do SD entirely within the TP layer.  I
>> suspect that if there were a way to do SD within the TP layer that made
>> everyone happy, we wouldn't have the approach propsed in
>> draft-rkhd-mpls-tp-sd.  And I think that if the motivation for this
>> draft is:
>> 
>> - we must have SD in TP because it is possible to do in other
>> technologies
>> - it is not possible to SD entirely within TP
>> - therefore we must get SD from somewhere else
>> 
>> is a reasonable one.  If we do that, where do we stop?  Should we
>> propagate information about signal quality up to TCP so it can adjust
>> its windows according?  (please note that this is intended to be a
>> reductio ad absurdum question and not a serious one. :) )
>> 
>> 
>> 
>> eric
>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of
>>> Greg Mirsky
>>> Sent: Wednesday, July 27, 2011 2:08 PM
>>> To: Daniel Cohn; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; D'Alessandro Alessandro
>>> Gerardo; [email-masked]
>>> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
>>> 
>>> Dear Authors and All,
>>> I think that it is function of the PHY layer to detect SD condition
>> and
>>> convert it into Down for the MPLS-TP Layer 0 (what we refer as
>> Physical
>>> Section). In case of accumulating SD over LSP the e2e Packet Loss
>>> measurement, in my view, is addressing the issue.
>>> 
>>> Regards,
>>> Greg
>> 
>> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls