The MPLS WG Archive

[Huub van Helvoort <hhelvoort@chello.nl>]

Stewart,

You replied:

>> [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.
> 
> ... but it would not be building a label stack it would be
> building a something else.

[hvh] then I suggest that you/your company writes a contribution
       explaining this and sent it to q9/15 proposing a correction
       to Y.1720

>> [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.
> 
> You can do lots of things if you are careful, but that does
> not mean that they should be done. We have no idea what
> the consequences of stray data in the stack are, or how
> they impact any developments we might wish to make in the
> future.
> 
>> [hvh] ehh, it was described in
>> http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-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.
> 
> Actually I see that you ran out of time at the meeting, and then
> not much.

==================== diclaimer ====================================
I (Huub van Helvoort), did not write/present this draft. So I could
not run out of time. (IETF64 was the first meeting I attended).
I am editor of Y.1720 since 2004 when this text was already
in the appendix. As an editor I can only change text by consensus
based on contributions and discussion during drafting.
===================================================================

I regret that I tried to help resolve this issue.

>> [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 am not sure that presenting a draft at one IETF meeting - which
> ran out of time - and then letting the draft die constitutes
> IETF approval for the design.

Before the contribution proposing the addition of this text
reached the ITU-T it has passed the USA approval process (maybe
ANSI, but at least SGB). Is was contributed as a USA contribution
so no US companies objected against the text.
Is it wrong to assume that these companies will ask their experts
to review such documents? and that some of these experts attend
IETF meetings?

Regards, Huub.

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

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