Subject: [conex] Draft agenda for Conex IETF-80

From: Nandita Dukkipati <[email-masked]>
Date: Tue, 22 Mar 2011 00:35:30 -0700

Hi.

Conex is scheduled to meet on Thursday afternoon (31 March) at Prague
IETF. Please find the draft agenda at this link:
http://www.ietf.org/proceedings/80/agenda/conex.txt

Please let us know if you have any suggestions on the agenda.

-Nandita

---

From: John Leslie <[email-masked]>
Date: Tue, 22 Mar 2011 08:58:17 -0400

> http://www.ietf.org/proceedings/80/agenda/conex.txt
]... 
] Suresh Krishnan
] An update on IPv6 options
] http://www.ietf.org/id/draft-krishnan-conex-ipv6-02.txt
] 20 minutes.

   This is unquestionably worth agenda time; but I also think it's
worth some discussion before Prague.

   Specifically, I think we need to be clearer about requirement 1:
] 
] R-1: The marking mechanism needs to be visible to all conex-capable
]      nodes on the path.

   Later in the draft, this is used to rule out Destination Options:
] 
] 4.2.  Destination options
] 
] The base IPv6 standard [RFC2460] defines the destination options.
] These options are processed only by the ultimate receiver of the
] packet (as specified in the Destination Address field) and not by
] nodes on the path.  Hence they do not meet R-1.

   That is not my interpretation of R-1.

   They're entirely "visible", being in a known place, easy to find,
well delineated so we could concentrate on exactly what we're looking
for.

   Furthermore, this seems to be where the 6MAN WG points everyone
who suggests adding a new Extension Header.

   I do not interpret R-1 to mean that ConEx marking needs to be
_observed_ by every node along the path.

--
John Leslie <[email-masked]>

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 22 Mar 2011 14:12:03 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John Leslie
> Sent: 22 March 2011 12:58
> To: [email-masked]
> Subject: [conex] draft-krishnan-conex-ipv6-02
> 

I agree that "visible" is not the same as "actively observed".

> who suggests adding a new Extension Header.

We would certainly be well advised to ensure our work is not in opposition
to 6MAN - there are more than enough problems as it is without creating new
ones. I have to say I haven't really been following 6MAN though so I can't
really comment on how sensible their advice is.

> _observed_ by every node along the path.

The key thing is that (some) ConEx marking may (possibly) need to be altered
along the path.

Bob had lots of stuff in an ID a couple of years ago talking about nodes
that effectively act as congestion control endpoints but which aren't at the
end of the e2e path. He had a natty name for these which I have completely
forgotten!

Toby

> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Mar 2011 19:06:17 +0000

Toby, John,

>I agree that "visible" is not the same as "actively observed".

Perhaps Suresh was thinking they would not be visible if IPsec ESP 
were used (I believe destination options are considered e2e and 
therefore encrypted). If so, it should be clear that IPsec is the 
constraint in this case, as there may be a work-round.

I think there are "absolute requirements" and "requirements with 
wriggle-room". For instance, there is perhaps a need to deploy ConEx 
in order to prove that it is worthwhile, so that there is a better 
case to take up IP header space for it. Then the initial deployment 
might have to rule out some constraints (like IPsec).

Not ideal, but ideal is the enemy of the good.

>The key thing is that (some) ConEx marking may (possibly) need to be altered

In requirements for the ConEx signal, abstract-mech says:

"The ConEx Signal SHOULD be immutable once set by the
        transport sender.
"
>end of the e2e path. He had a natty name for these which I have completely

I think you're looking for "load regulator". This is a node 
potentially midpath that receives feedback and regulates load. PWE3 
has some scenarios like this. So does PCN.

Also there might be "sender proxy" scenarios.

These nodes are effectively acting as the sender, but I guess we need 
to think about this some more.

E.g.
How a mid-path sender-proxy that wants to set ConEx signals interacts 
with the original source that might have deliberately not set ConEx.

And exactly what is a mid-path load regulator allowed to do with 
ConEx signals, because effectively these architectures dived a path 
up into segments, each with their own congestion control feedback loop?

But perhaps these are corner-cases?

Bob

>Toby

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 22 Mar 2011 18:21:12 -0400

Hi John,

> well delineated so we could concentrate on exactly what we're looking

Given the current state of IPv6, an intermediate node is not allowed to 
even examine destination options. Unfortunately, RFC2460 does not follow 
RFC2119 language. The following text is present in Section 4.

"With one exception, extension headers are not examined or processed
  by any node along a packet's delivery path, until the packet reaches
  the node (...) identified in the Destination Address field of the IPv6
  header"

The exception of course is the Hop-by-hop extension header. Of course we 
can code conex aware routers on-path to look into the dest opts header, 
but that will rule out IPsec ESP protected packets (as Bob pointed out). 
This is of course a limitation we can decide to live with, but once the 
flow label bits are gone, they are gone forever :-(.

> who suggests adding a new Extension Header.

Correct. But extension headers and dest opts have end-to-end 
significance and not hop-by-hop significance. So I think that the 
recommendation is sound.

> _observed_ by every node along the path.

I was more thinking that the marking needs to be _observable_ by every 
node along the path, and a dest option is not legally observable by an 
intermediate node.

Thanks
Suresh

---

From: John Leslie <[email-masked]>
Date: Wed, 23 Mar 2011 15:43:15 -0400

>  the node (...) identified in the Destination Address field of the IPv6

   As you said, that doesn't include any MUSTard.

   IMHO, Section 4 is there stating an expectation, not a requirement.
I don't recall that specific question being addressed in 6MAN, but there
is a clear understanding there that there's nothing to prevent deep-
packet inspection.

> flow label bits are gone, they are gone forever :-(.

   It's not _quite_ that cut-and-dried.

   RFC2460 "recommends" an order of headers that puts Authentication and
Encapsulating Security headers before Destination Options, but _requires_
IPv6 nodes to accept headers in any order.

   In any case, IPsec is probably not an issue for our initial Experimental
spec.

> significance and not hop-by-hop significance. So I think that the 

   Which recommendation?

> node along the path, and a dest option is not legally observable by an 

   I dissent on "not legally observable". I suppose we could put that
question to the 6MAN WG, but I'm not sure I can guarantee an answer...

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 26 Mar 2011 06:05:37 -0400

Hi John,

> From: John Leslie [mailto:[email-masked]] 
> Sent: Wednesday, March 23, 2011 8:43 PM
> To: Suresh Krishnan
> Cc: [email-masked]
> Subject: Re: [conex] draft-krishnan-conex-ipv6-02
> 
> > Given the current state of IPv6, an intermediate node is 
> not allowed 
> > to even examine destination options. Unfortunately, RFC2460 
> does not 
> > follow

Correct. This is true for all of RFC2460.

> I don't recall that specific question being addressed in 
> 6MAN, but there is a clear understanding there that there's 
> nothing to prevent deep- packet inspection.
> 
> > The exception of course is the Hop-by-hop extension header. 
> Of course 
> > we can code conex aware routers on-path to look into the dest opts 
> > header, but that will rule out IPsec ESP protected packets 
> (as Bob pointed out).
> > This is of course a limitation we can decide to live with, but once 
> > the flow label bits are gone, they are gone forever :-(.
> 
>    RFC2460 "recommends" an order of headers that puts 
> Authentication and Encapsulating Security headers before 
> Destination Options, but _requires_

The order of the headers is not the issue. The issue is that ESP would encrypt the dest opts header so that it would not be visible.

> 
>    In any case, IPsec is probably not an issue for our 
> initial Experimental spec.
> 
> >> Furthermore, this seems to be where the 6MAN WG points 
> everyone who 
> >> suggests adding a new Extension Header.
> > 

That destination options should be used instead of extension hedaers for carrying optional data with end-to-end significance.

>    I dissent on "not legally observable". I suppose we could 
> put that question to the 6MAN WG, but I'm not sure I can 
> guarantee an answer...

I guess a lot of intermediate nodes do a lot more than look at the IP header, and this is common practice. But that does not make it legal :-). In either case, I contend that a destination option cannot be observed by conex-aware nodes at wire speed, and will hit the same issues as the hop-by-hop options. The only saving grace is that the non-conex aware intermediate nodes will not get tripped up over dest opts.

Thanks
Suresh