Subject: RE: [PWE3] Y.1720 liased text

From: <[email-masked]>
Date: Fri, 26 Jan 2007 07:43:06 -0000

Thanks Huub, 

Can you clarify how the S bit is set when this 1+1 seq no. field is
used?  What is puzzling me is this sentence in the text Stewart
extracted from Y.1720/Appendix 11:

"Note that packet 1+1 can be provided at any level of the hierarchy of a
nested LSP."

I sort-of read this as there can be a set of nested LSPs (hence
concatenated MPLS headers) and that the protection mechanism can be
applied to any one of these within such a stack.  Am I reading this
right?

If I am, then please see my concerns of yesterday on this
thread....which, in essence, is querying what happens if there is
misconnectivity and the LSP carrying the 1+1 Seq No. stuff arrives at
some arbitrary LSR.....how will that LSR parse/interpret the fields it
sees?

I have no background on Y.1720, so my apologies if I am asking a dumb
question.

regards, Neil

> -----Original Message-----
> From: Huub van Helvoort [mailto:[email-masked]] 
> Sent: 25 January 2007 21:50
> To: Trowbridge, Stephen J (Steve)
> Cc: [email-masked]; Ghani Abbas (BE/ETL); pwe3; Stewart Bryant
> Subject: Re: [PWE3] Y.1720 liased text
> 
> 
> Hello Steve,
> 
> You wrote:
> 
> > Hi Stewart,
> > I am not really close enough to Y.1720 to respond regarding the 
> > technical content, but what was just approved is not a new 
> > Recommendation. It is a minor maintenance update to a 
> Recommendation 
> > originally developed in ITU-T Study Group 13 that has been in force 
> > since April 2003. All protection switching work was 
> collected together 
> > in ITU-T Study Group 15 with the reorganization of work at 
> the end of 
> > 2004, so it fell to us (WP3/15 chair hat on) to do the maintenance 
> > update.
> > 
> > If anyone on this list is more familiar with original 
> Y.1720 than me, 
> > I think it would be helpful to know whether you think that we broke 
> > something in the process of doing the maintenance update, 
> or if these 
> > are new concerns being raised in 2007 about a document that 
> has been 
> > approved and in force since 2003?
> 
> It was indeed a maintenance update. The previous version was 
> consented in the 07/2003 plenary and approved in 09/2003.
> 
> The Appendix mentioned was not altered after that revision,
> so this text is there for three years.
> 
> Regards, Huub (editor of Y.1720).
> 
> 
> > -----Original Message-----
> > From: Stewart Bryant [mailto:[email-masked]]
> > Sent: Thursday, January 25, 2007 8:43 AM
> > To: pwe3
> > Cc: [email-masked]
> > Subject: [PWE3] Y.1720 liased text
> > 
> > Please could some else from the PWE3 WG take a look at the 
> following 
> > liaison statement.
> > 
> > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=289
> > 
> > I think that we need to respond with the following, but I 
> would like 
> > someone else to check my interpretation of their text and the IETF 
> > MPLS design.
> > 
> > An appropriate response would seem to be:
> > 
> > 
> > The PWE3 WG is concerned about the consented text for 
> Y.1720 that has 
> > been liaised to us.
> > 
> > In particular the following text in Y.1720 looks like a 
> violation of 
> > the IETF MPLS architecture.
> > 
> > Appendix II
> > 
> > Packet 1+1 example realization
> > The packet 1+1 scheme can be implemented by using a sequence as an 
> > identifier. The sequence number can be carried as the first 
> four bytes 
> > inside the shim header of the LSP providing packet 1+1. Since the 
> > ingress and egress nodes must be aware of each LSP participating in 
> > the packet 1+1, the egress node will recognize that there is a 
> > sequence number inside the label. It will use the sequence 
> number for 
> > selection purpose and then remove it before forwarding the accepted 
> > packet further. Note that packet 1+1 can be provided at any 
> level of 
> > the hierarchy of a nested LSP. Figure II.1 illustrates the sequence 
> > number position behind the 4-bytes MPLS encapsulation header.
> > 
> > 
> > This implies that the Y.1720 is proposing to place an item in the 
> > label stack that does not conform to the design of an RFC3032 label 
> > stack entry.
> > 
> > This breaks the MPLS invariant that any item that follows 
> an LSE with 
> > the S bit set to zero MUST be another LSE.
> > 
> > It also breaks the guideline that any item that follows a MPLS LSE 
> > should either be an IP packet or should conform to the design 
> > described in RFC4385.
> > 
> > It is our view that all MPLS packet designs must adhere to 
> the design 
> > invariants and guidelines produced by the IETF and the text in 
> > Appendix II, and any technical design that conflicts with the IETF 
> > design needs amendment before Y.1720 is published in its final form.
> > 
> > Regards
> > 
> > Stewart
> 
> -- 
> ================================================================
>                    http://www.van-helvoort.eu/ 
> ================================================================
> Always remember that you are unique...just like everyone else...
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 26 Jan 2007 13:09:46 +0100

Hello Neil,

You responded:

> used? 

I checked the appendix II twice (because my left eye is still 10%),
I could not find any text referring to setting the S bit.
I only see that the 4 octet sequence number is placed right
after the shim header.

> What is puzzling me is this sentence in the text Stewart

I agree with your reading.

> I have no background on Y.1720, so my apologies if I am asking a dumb

There are no dumb questions, only dumb answers. Maybe this is one:

This morning I did some further investigating where the text originates
and found it in the IETF archives:
http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-packet-protection-00.txt

It was also discussed on the MPLS WG list and there I found the
answer to your concerns expressed above (provided by yourself ;-)

http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00211.html

Cheers, Huub.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Jan 2007 12:17:07 +0000

> I only see that the 4 octet sequence number is placed right

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?

If so what is the setting of the S bit (See RFC3032) in each
case?

- Stewart

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 26 Jan 2007 13:27:13 +0100

Hello Steward,

> The implication of the text is that you can have a packet of the

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

Because the text does not mention any altering of the S-bit
I assume they do not change.

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.

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.

Regards, Huub.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Jan 2007 14:39:48 -0000

Hi Huub,

> I assume they do not change.

Ah, so either setting of the S-bit is allowed?

> both ends support this feature and closely guard the connectivity

With the S-bit, careful config is needed.

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

> 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

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

Cheers,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 26 Jan 2007 20:03:14 +0100

Hi Adrian,

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

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

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

> what deployed implementations do?

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

Cheers, Huub.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Jan 2007 19:31:19 +0000

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

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

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

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

Stewart

---

From: "BRUNGARD, DEBORAH A, SBCLABS" <[email-masked]>
Date: Fri, 26 Jan 2007 14:02:36 -0600

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:[email-masked]] 
Sent: Friday, January 26, 2007 2:03 PM
To: Adrian Farrel
Cc: [email-masked]; [email-masked]; [email-masked]; Stewart
Bryant
Subject: Re: [PWE3] Re: Y.1720 liased text

Hi Adrian,

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

Cheers, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 26 Jan 2007 21:29:19 +0100

Stewart,

> 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

> Actually I see that you ran out of time at the meeting, and then

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

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

---

From: "Ghani Abbas \(BE/ETL\)" <[email-masked]>
Date: Sat, 27 Jan 2007 21:04:25 +0100

Adrain and Stewart,
 
It seems to me the discussion about an issue in Y.1720 which has been in the public domain for a long time.
In order to resolve the issue I suggest that a contribution be submitted to the next Q9/15 meeting ( either 12th., Feb or 10th.,April meetings). Q9/15 can discuss the issue and may recommend a way forward.
 
Ghani

________________________________

From: Adrian Farrel [mailto:[email-masked]]
Sent: Fri 26/01/2007 15:39
To: Huub van Helvoort; Stewart Bryant
Cc: [email-masked]; Ghani Abbas (BE/ETL); [email-masked]; [email-masked]
Subject: Re: [PWE3] Re: Y.1720 liased text

Hi Huub,

Hmmm.

Cheers,
Adrian