The MPLS WG Archive

["BRUNGARD, DEBORAH A, SBCLABS" <dbrungard@att.com>]

FYI-
This 1+1 packet protection scheme was not only in ITU's SG13 work, it
was also included in SG15's G.7712, done at the same time (2003). G.7712
doesn't reference Y.1720, probably as they were being done at the same
time, though the scheme was of the same origin.

G.7712's Appendix IV does say that the implementation is "non-trivial",
maybe there have been no attempts.

(ITU Recommendations (PDF) can be downloaded for free)

Deborah   

-----Original Message-----
From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
Sent: Friday, January 26, 2007 2:03 PM
To: Adrian Farrel
Cc: mpls@ietf.org; ghani.abbas@ericsson.com; pwe3@ietf.org; Stewart
Bryant
Subject: Re: [PWE3] Re: Y.1720 liased text

Hi Adrian,

You wrote:

> Hi Huub,
> 
>>> The implication of the text is that you can have a packet of the
>>> form:
>>>
>>> LSE (RFC3032)
>>> Sequence number
>>> LSE (RFC3032)
>>> Payload
>>>
>>> Is that correct?
>>
>> This is also what I read, and apparently Neil does as well.
>>
>>> If so what is the setting of the S bit (See RFC3032) in each
>>> case?
>>
>> Because the text does not mention any altering of the S-bit
>> I assume they do not change.
> 
> Ah, so either setting of the S-bit is allowed?

[hvh] the text does also not mention a specific value of the S-bit,
       so I suppose either value of the S-bit is allowed.
       If I would try to implement this protection, the LSR
       providing the protection would build the LSE according to
       RFC3032 and then add the 4 octet sequence number.

>> I agree with Neil (see his 2002 post) that this requires a
>> very carefull configuartion of the network. Checking that
>> both ends support this feature and closely guard the connectivity
>> for both diverse routes.
> 
> With the S-bit, careful config is needed.

[hvh] indeed I did mean careful

> Without the S-bit it seems like a router that popped a label would 
> expect the next thing on the stack to also be a label, but would 
> actually find a magic sequence number.

[hvh] if the the config was careful the router that pops the
label inserted by the router that is the source of the protection
knows that the 4 octets following this popped label is the
sequene number and treats it accordingly.

> Although you could config around 
> this (since the pop action must be installed) this is a new MPLS 
> behavior. At the least it is a new LFIB action that is not previously 
> described in any MPLS documentation.

[hvh] ehh, it was described in
http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-pro
tection-00.txt
       This draft was presented and discussed in the IETF53 meeting.
       The meeting notes nor the discussion afterwards on the MPLS WG
list
       mention the fact that it contains a new LFIB action.

>> Note that this text is in an appendix, so it does not form
>> an integral part of the recommendation, i.e. it is not mandatory.
> 
> Hmmm.
> 
> Shouldn't there be a specification of:
> - what must be supported
> - what can also be attempted

[hvh] maybe, but apparently when the text was drafted there were no
       contributions providing/requesting these specifications, and
       when the recommendation was approved (as usual in ITU-T by
       consensus) nobody objected, in the meeting of the Q3/13, at
       the closing plenary, nor during the AAP.

> I think Stewart's question is quite helpful here. Do we have any idea
of 
> what deployed implementations do?

[hvh] That would be a question to ask on the ITU-T Q9/15 exploder

> Cheers,
> Adrian

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls