headers
Joe Touch | 7 Sep 2005 22:50
Picon
Favicon

Re: ICMP-MPLS


I had a question about the current state of draft-ietf-mpls-icmp-03:

I'm concerned about the issue of backward compatibility, notably the
ways in which the use of the extensions proposed will cause existing
ICMP processing to break, notably binding the length of the final field
to 128 bytes, esp. considering RFC1812 recommends:

   Therefore, the ICMP
   datagram SHOULD contain as much of the original datagram as possible
   without the length of the ICMP datagram exceeding 576 bytes

Given that, it seems that this new variant of ICMP message (which
includes headers before IP, rather than IP and thereafter - which is
curious enough in itself) ought to demand a new message type, which
necessatates use of the "Parameter Problem" code, or the definition of
other new codes. Inside those, the new format that uses a list of
pointers to include MPLS information might be appropriate.

Use of the "unused" area, as Ron suggested, seems inappropriate because
those fields are not known to be 'cleared' by existing ICMP sources, so
their value cannot be reliably used for flags IMO.

Pekka wrote:
> So, publish the current draft as Informational with a suitable  note 
> saying that this is the currently deployed practise, stating  that 
> there are architectural problems in the way it is done, and  that
> the  practise should not be extended?  And at the same time,  try to
> do the  right thing for IPv6, and possible future IPv4  extensions?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joe Touch | 8 Sep 2005 00:24
Picon
Favicon

Re: ICMP-MPLS


PS:

Joe Touch wrote:
> I had a question about the current state of draft-ietf-mpls-icmp-03:
> 
> I'm concerned about the issue of backward compatibility, notably the
> ways in which the use of the extensions proposed will cause existing
> ICMP processing to break, notably binding the length of the final field
> to 128 bytes, esp. considering RFC1812 recommends:
> 
>    Therefore, the ICMP
>    datagram SHOULD contain as much of the original datagram as possible
>    without the length of the ICMP datagram exceeding 576 bytes
> 
> Given that, it seems that this new variant of ICMP message (which
> includes headers before IP, rather than IP and thereafter - which is
> curious enough in itself) ought to demand a new message type, which
> necessatates use of the "Parameter Problem" code, or the definition of
> other new codes. Inside those, the new format that uses a list of
> pointers to include MPLS information might be appropriate.

One possible solution to the use of new codes, and the need for
compatibility with old programs:

	Send two ICMP error messages

I.e., for a particular message, send

	ICMP type 3 code 0 net unreachable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Nikander | 8 Sep 2005 09:34

Re: ICMP-MPLS

Joe,

There are two separate issues here:

   - creating a document for the current practise, with strong
     enough disclaimers and at the same time trying to do it
     as "right" as possible

   - doing the right thing for IPv6

AFAIK, Ron is working on a new version of the current draft to
include comments from the discussion here, and to add a field
to the reserved field to make the extension a little bit better
in syntactical terms.  I've promised to review and help him once
he gets a reasonable version.

I am not aware of anyone working on the IPv6 issues.  I think
the MPLS WG should charter an item there is any real life
interest; otherwise it can wait, at least as far as I am
concerned.  Before that we just must make sure that the
current IPv4 practise is NOT adopted for IPv6.

Now, taking a technical step back, the issues is pretty
complicated since there are different uses of MPLS.  In some
cases MPLS is used more-or-less as a link layer protocol, and
the argumentation that appeared here and that you continue
holds pretty well.  However, in other cases MPLS is used more
as a source routing mechanism for IP.  That is, instead of
using the usual hop-by-hop IP routing based on routing tables
created by a routing protocol, the MPLS ingress router (Label
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joe Touch | 8 Sep 2005 17:31
Picon
Favicon

Re: ICMP-MPLS


Pekka Nikander wrote:
> Joe,
> 
> There are two separate issues here:
> 
>   - creating a document for the current practise, with strong
>     enough disclaimers and at the same time trying to do it
>     as "right" as possible
> 
>   - doing the right thing for IPv6
> 
> AFAIK, Ron is working on a new version of the current draft to
> include comments from the discussion here, and to add a field
> to the reserved field to make the extension a little bit better
> in syntactical terms.  I've promised to review and help him once
> he gets a reasonable version.
> 
> I am not aware of anyone working on the IPv6 issues.  I think
> the MPLS WG should charter an item there is any real life
> interest; otherwise it can wait, at least as far as I am
> concerned.  Before that we just must make sure that the
> current IPv4 practise is NOT adopted for IPv6.
> 
> Now, taking a technical step back, the issues is pretty
> complicated since there are different uses of MPLS.  In some
> cases MPLS is used more-or-less as a link layer protocol, and
> the argumentation that appeared here and that you continue
> holds pretty well.  However, in other cases MPLS is used more
> as a source routing mechanism for IP.  That is, instead of
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pekka Savola | 9 Sep 2005 08:32
Picon

Re: Please review: draft-savola-mtufrag-network-tunneling-04.txt

On Tue, 30 Aug 2005, Joe Touch wrote:
>> I think we just have to agree to disagree.  Over half a dozen people
>> have stated that they find the draft very useful, and at least two ADs
>> have been willing to sponsor it.  There have also been discussion on
>> various lists, particularly form the ops perspective (e.g.,
>> http://www.merit.edu/mail.archives/nanog/2004-10/threads.html#00125).
>
> A quick scan of that list didn't note anyone who saw the relationship to
> RFC2003. Since the I-D didn't cite that, the (IMO) definitive current
> work on the topic, it's not clear what the positive input on this draft
> really means (maybe that they should read RFC2003, i.e.).

If it makes you happier, I could try querying the folks on whether 
they think the draft is useful after taking a look at RFC 2003 -- if 
you provide the list of section numbers of RFC 2003 I should refer 
them to read in particular.

I'm pretty sure I already know the answer, but if that helps you drop 
the argument, I can try it..

>> The text in the draft says,
>>
>>    When desiring to avoid fragmentation, IPv4 allows two options: copy
>>    the DF bit from the inner packets to the encapsulating header, or
>>    always set the DF bit.  The latter is better especially in controlled
>>    environments, because it forces PMTUD to converge immediately.
>>
>> Both of these fulfill the MUST you quote: if it's copied (when DF is
>> set), it's also set for the outer header; when it's forced, it's always
>> set.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Spencer Dawkins | 9 Sep 2005 18:09
Favicon

(Late) Meeting minutes and presentations for Int-Area

While some of us still remember Paris,

Could you look at the posted minutes and see if you remember anything that I 
may have missed or misconstrued?

The deadline for submitting corrections is Monday, September 19, 2005 at 
17:00 ET.

https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=63

Thanks!

Spencer
Permalink | Reply | 0 comments |
headers
Pekka Nikander | 14 Sep 2005 15:12

Re: ICMP-MPLS

Joe,

>> Now, taking a technical step back, the issues is pretty  
>> complicated since there are different uses of MPLS.  In some cases  
>> MPLS is used more-or-less as a link layer protocol, and the  
>> argumentation that appeared here and that you continue holds  
>> pretty well.  However, in other cases MPLS is used more as a  
>> source routing mechanism for IP.  That is, instead of using the  
>> usual hop-by-hop IP routing based on routing tables created by a  
>> routing protocol, the MPLS ingress router (Label Edge Router)  
>> creates an MPLS "tunnel" (Label Switch Path) to the MPLS egress  
>> router, using the information from the very same routing tables.
>>
>> Note that in the latter usage the route that the IP packets take  
>> is exactly the same, using exactly the same routing information.   
>> Hence, there is no difference between plain IP routing and MPLS- 
>> based IP routing. The difference lies in the forwarding plane,  
>> where in plain IP case each box in the path examines the IP header  
>> and makes the forwarding decision based on it while in the MPLS  
>> case the forwarding decision is based on the MPLS label prepended  
>> to the IP packet.  In other words, in the plain IP case the  
>> forwarding decision is done individually at each router (hop-by- 
>> hop forwarding decision) while in the MPLS case the forwarding  
>> decision is effectively done at the ingress router, in a sort-of  
>> source-routing fashion.
>>
>
> In this case MPLS is equivalent to a tunneling mechanism; whereas  
> it's OK to cache (i.e., bury) forwarding steps in a tunnel  
> mechanism, it necessarily hides it from the IP layer.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joe Touch | 14 Sep 2005 17:13
Picon
Favicon

Re: ICMP-MPLS

Comments below...

Pekka Nikander wrote:
> Joe,
> 
>>> Now, taking a technical step back, the issues is pretty  complicated
>>> since there are different uses of MPLS.  In some cases  MPLS is used
>>> more-or-less as a link layer protocol, and the  argumentation that
>>> appeared here and that you continue holds  pretty well.  However, in
>>> other cases MPLS is used more as a  source routing mechanism for IP. 
>>> That is, instead of using the  usual hop-by-hop IP routing based on
>>> routing tables created by a  routing protocol, the MPLS ingress
>>> router (Label Edge Router)  creates an MPLS "tunnel" (Label Switch
>>> Path) to the MPLS egress  router, using the information from the very
>>> same routing tables.
>>>
>>> Note that in the latter usage the route that the IP packets take  is
>>> exactly the same, using exactly the same routing information.  
>>> Hence, there is no difference between plain IP routing and MPLS-
>>> based IP routing. The difference lies in the forwarding plane,  where
>>> in plain IP case each box in the path examines the IP header  and
>>> makes the forwarding decision based on it while in the MPLS  case the
>>> forwarding decision is based on the MPLS label prepended  to the IP
>>> packet.  In other words, in the plain IP case the  forwarding
>>> decision is done individually at each router (hop-by- hop forwarding
>>> decision) while in the MPLS case the forwarding  decision is
>>> effectively done at the ingress router, in a sort-of  source-routing
>>> fashion.
>>>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Narten | 15 Sep 2005 17:44
Picon
Favicon

concerns about draft-ietf-ipv6-ndproxy-03.txt

I'm sending this to the int-area because the concerns I have are
broader than the just the ipv6 WG. This document is really about
bridging/proxy arp in general, and it does not restrict itself to
IPv6; it also covers IPv4.

I've read this document a couple of times (it is on the IESG's plate
to review), but have general concerns. I wonder if others in the
community share my concern.

The bottom line is that I think the IPv6 portion of document/protocol
is both under-specified and too broad in scope and I worry that there
are a lot of potential gotchas lurking. I also worry that it will
break some of our standards track protocols. And if it gets widely
implemented, we'll have to deal with the resultant mess. We have
plenty of experience in IPv4 with proxy arp, and some of it has been
unpleasant.

I have the following meta concerns:

1) I do not believe the material on IPv4 ARP proxy should be
included. It is not in-scope for the IPv6 WG to be developing it, and
any document on proxy ARP in IPv4 really requires review from the
broader community. AFAIK, that review has not taken place.

Recommendation: remove the IPv4 material and place in a separate
document

2) This document breaks SEND (but does not say this clearly). I have
doubts that we should be publishing documents that break our standards
track protocols (especially ones that we believe are important). Or at
(Continue reading)

Permalink | Reply | 1176 comments |
headers
Joe Touch | 15 Sep 2005 20:09
Picon
Favicon

Re: Please review: draft-savola-mtufrag-network-tunneling-04.txt


Pekka Savola wrote:
> On Tue, 30 Aug 2005, Joe Touch wrote:
> 
>>> I think we just have to agree to disagree.  Over half a dozen people
>>> have stated that they find the draft very useful, and at least two ADs
>>> have been willing to sponsor it.  There have also been discussion on
>>> various lists, particularly form the ops perspective (e.g.,
>>> http://www.merit.edu/mail.archives/nanog/2004-10/threads.html#00125).
>>
>>
>> A quick scan of that list didn't note anyone who saw the relationship to
>> RFC2003. Since the I-D didn't cite that, the (IMO) definitive current
>> work on the topic, it's not clear what the positive input on this draft
>> really means (maybe that they should read RFC2003, i.e.).
> 
> If it makes you happier, I could try querying the folks on whether they
> think the draft is useful after taking a look at RFC 2003 -- if you
> provide the list of section numbers of RFC 2003 I should refer them to
> read in particular.
> 
> I'm pretty sure I already know the answer, but if that helps you drop
> the argument, I can try it..

It'd be useful either way. The fact that they didn't notice 2003's
omission in the first place suggests they might not be the appropriate
group to poll on whether a new RFC on this issue is useful, though.

...
>>>> This is just making a decision at the tunnel that you prefer efficiency
(Continue reading)

Permalink | Reply | 4 comments |

Gmane