Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
Hi Adrian,
See feedback below [dasmith].
Adrian> UFrom mpls-bounces at ietf.org Sun Nov 2 01:33:31 2008
Return-Path: <mpls-bounces at ietf.org>
X-Original-To: mpls-archive at megatron.ietf.org
Delivered-To: ietfarch-mpls-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 224633A6912;
Sun, 2 Nov 2008 01:33:31 -0700 (PDT)
X-Original-To: mpls at core3.amsl.com
Delivered-To: mpls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id DF88E3A699E
for <mpls at core3.amsl.com>; Sun, 2 Nov 2008 01:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id HHXLEKvYqOZD for <mpls at core3.amsl.com>;
Sun, 2 Nov 2008 01:33:28 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148])
by core3.amsl.com (Postfix) with ESMTP id C2F2D3A6781
for <mpls at ietf.org>; Sun, 2 Nov 2008 01:33:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,529,1220227200"; d="scan'208";a="26483652"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2008 08:33:23 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA28XNXX011300;
Sun, 2 Nov 2008 03:33:23 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
[64.102.31.12])
by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA28XNZ5029676;
Sun, 2 Nov 2008 08:33:23 GMT
Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by
xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Sun, 2 Nov 2008 03:33:23 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 2 Nov 2008 03:32:08 -0500
Message-ID: <42591A81B59EA14BAA617596482F65CE05F459D4 at xmb-rtp-212.amer.cisco.com>
In-Reply-To: <C48632358EF74F6595B4090FF4B42A39 at your029b8cecfe>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
Thread-Index: Ack4j8OLlmU6BgJhTzGF78sZEikMWQEGHKXA
From: "David Smith (djsmith)" <djsmith at cisco.com>
To: "Adrian Farrel" <adrian at olddog.co.uk>, <mpls at ietf.org>
X-OriginalArrivalTime: 02 Nov 2008 08:33:23.0351 (UTC)
FILETIME=[AB189A70:01C93CC5]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14277; t=1225614803;
x=1226478803; c=relaxed/simple; s=rtpdkim2001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=djsmith at cisco.com;
z=From:=20=22David=20Smith=20(djsmith)=22=20<djsmith at cisco.c
om> |Subject:=20RE=3A=20[mpls]=20draft-dasmith-mpls-ip-options-
01.txt=20as=20a=20WG=20doc? |Sender:=20
|To:=20=22Adrian=20Farrel=22=20<adrian at olddog.co.uk>,=20<mp
ls at ietf.org>; bh=cr6f8k3qaW96tc3qSLJcAMXtHWQzhq3dUt+J7xVwIuM=;
b=fuW7BfEB8nU44Gx2hdHTKvZgMi2aXqDDBwD+kLCzyQVp5jFXERV05X6s0Z
ge0tOKg5PudReZEpp49xauKC/zRT/x99NxligSodGer/y5580A3FjpJDo98D
BrpmXDHcIp;
Authentication-Results: rtp-dkim-2; header.From=djsmith at cisco.com; dkim=pass (
sig from cisco.com/rtpdkim2001 verified; );
Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
X-BeenThere: mpls at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls>
List-Post: <mailto:mpls at ietf.org>
List-Help: <mailto:mpls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mpls-bounces at ietf.org
Errors-To: mpls-bounces at ietf.org
Hi Adrian,
See feedback below [dasmith].
Adrian> Unlike Renlike Renwei, I'm not too worried about experimental options. I
don't think these are supposed to escape into the wider network, so we
should not let them drive our decision-making.
[dasmith] Note, as stated in the draft (section 4), processing of IP
header options (of any type) at the LER is outside the scope of this
draft. Namely, it is not relevant to MPLS whether the IP header option
is processed or not by the LER. What is relevant, is whether such IP
option packets bypass MPLS encapsulation when the LER's assigned
prefix-based FEC specifies a MPLS LSP tunnel.
Adrian> However, I do agree that it worrying to make this standards
track. It really does seem to be trying to define as mandatory an
implementation behavior that might reasonably be flexible for different
reasons.
[dasmith] The intent is only to define the proposed LER behavior as
mandatory to implement, not to prohibit LER flexibility. We can refine
the text to make clearer if adopted by the WG.
Adrian> If the use of IP options in the core is sufficiently worrying,
why not disable them on the core routers?
[dasmith] Because this doesn't solve the fundamental issue that in many
environments core routers (ie, LSRs) don't carry the BGP routes
necessary to IP route such packets downstream. If your suggesting that
core routers simply drop such packets, this may actually break transit
applications that use IP option packets legitimately. All this draft is
proposing is support for MPLS encapsulation of IP option packets when
the LER's assigned prefix-based FEC specifies a MPLS LSP tunnel. Namely,
by default, when an ingress LER is determining whether to push an MPLS
label stack onto an IP packet, the determination is made without
considering any IP options that may be carried in the IP packet header.
This mitigates the security risks while not breaking transit
applications that legitimately use IP option pkts.
Adrian> If two IP packets carry different explicit paths in their
options, why should they not be directed to different (explicitly
routed) LSPs to conform to those routes even though they carry the same
FEC?
[dasmith] We can refine the text to make LER flexibility clearer if
adopted by the WG. However, would you agree that most SPs do not process
source route options today, hence, this should not be the default
behavior? And IP routing not be the only supported behavior?
Adrian> There are plenty of questions like these and I don't feel that
requiring an LER to conform to some behavior is beneficial.
[dasmith] We are only proposing that ingress LERs support a forwarding
rule whereby option pkts (by default) use an MPLS LSP if the matching
prefix-based FEC specifies one.
Adrian> Additionally, will you also be specifying the correct behavior
of an LSR that receives an IP packet that carries options but that is
not carried by an LSP when the LSR believes the packet should be carried
by an LSP?
[dasmith] An LSR will behave normally. No specification needed. An LSR
will forward received MPLS packets using the MPLS label header. An LSR
will forward received IP packets using the IP header. If no IP route for
the IP destination (of a non-labelled IP packet), the LSR will drop the
packet as expected. An LSR cannot traceback what LSP it believes this
packet should have come in on. It routes based on the received pkt
header, and therein lies the problem with packets that fail to be MPLS
encapsulated at the LER. Ie, the LSR may not be able to route them using
IP header info. Even if the LSR had the necessary IP routing
information, there are many security risks (as outlined in Section 5)
that result from IP option pkts that bypass MPLS encapsulation.
Adrian> Now, if you made the I-D advice with suitable warnings, I might
take a different view. This would be an Informational I-D not a BCP. I
would prefer more time to be spent discussing these ideas before the
working group decides to embrace this work.
[dasmith] There are security implications here so it is my hope the WG
embraces this work. We can certainly refine its text to make LER
flexibility clearer inwei, I'm not too worried about experimental options. I
don't think these are supposed to escape into the wider network, so we
should not let them drive our decision-making.
[dasmith] Note, as stated in the draft (section 4), processing of IP
header options (of any type) at the LER is outside the scope of this
draft. Namely, it is not relevant to MPLS whether the IP header option
is processed or not by the LER. What is relevant, is whether such IP
option packets bypass MPLS encapsulation when the LER's assigned
prefix-based FEC specifies a MPLS LSP tunnel.
Adrian> However, I do agree that it worrying to make this standards
track. It really does seem to be trying to define as mandatory an
implementation behavior that might reasonably be flexible for different
reasons.
[dasmith] The intent is only to define the proposed LER behavior as
mandatory to implement, not to prohibit LER flexibility. We can refine
the text to make clearer if adopted by the WG.
Adrian> If the use of IP options in the core is sufficiently worrying,
why not disable them on the core routers?
[dasmith] Because this doesn't solve the fundamental issue that in many
environments core routers (ie, LSRs) don't carry the BGP routes
necessary to IP route such packets downstream. If your suggesting that
core routers simply drop such packets, this may actually break transit
applications that use IP option packets legitimately. All this draft is
proposing is support for MPLS encapsulation of IP option packets when
the LER's assigned prefix-based FEC specifies a MPLS LSP tunnel. Namely,
by default, when an ingress LER is determining whether to push an MPLS
label stack onto an IP packet, the determination is made without
considering any IP options that may be carried in the IP packet header.
This mitigates the security risks while not breaking transit
applications that legitimately use IP option pkts.
Adrian> If two IP packets carry different explicit paths in their
options, why should they not be directed to different (explicitly
routed) LSPs to conform to those routes even though they carry the same
FEC?
[dasmith] We can refine the text to make LER flexibility clearer if
adopted by the WG. However, would you agree that most SPs do not process
source route options today, hence, this should not be the default
behavior? And IP routing not be the only supported behavior?
Adrian> There are plenty of questions like these and I don't feel that
requiring an LER to conform to some behavior is beneficial.
[dasmith] We are only proposing that ingress LERs support a forwarding
rule whereby option pkts (by default) use an MPLS LSP if the matching
prefix-based FEC specifies one.
Adrian> Additionally, will you also be specifying the correct behavior
of an LSR that receives an IP packet that carries options but that is
not carried by an LSP when the LSR believes the packet should be carried
by an LSP?
[dasmith] An LSR will behave normally. No specification needed. An LSR
will forward received MPLS packets using the MPLS label header. An LSR
will forward received IP packets using the IP header. If no IP route for
the IP destination (of a non-labelled IP packet), the LSR will drop the
packet as expected. An LSR cannot traceback what LSP it believes this
packet should have come in on. It routes based on the received pkt
header, and therein lies the problem with packets that fail to be MPLS
encapsulated at the LER. Ie, the LSR may not be able to route them using
IP header info. Even if the LSR had the necessary IP routing
information, there are many security risks (as outlined in Section 5)
that result from IP option pkts that bypass MPLS encapsulation.
Adrian> Now, if you made the I-D advice with suitable warnings, I might
take a different view. This would be an Informational I-D not a BCP. I
would prefer more time to be spent discussing these ideas before the
working group decides to embrace this work.
[dasmith] There are security implications here so it is my hope the WG
embraces this work. We can certainly refine its text to make LER
flexibility clearer if adoptef adopted by the WG.
Regards,
/dave
-----Original Message-----
From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of
Adrian Farrel
Sent: Monday, October 27, 2008 7:57 PM
To: mpls at ietf.org
Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
I too am a bit concerned about this draft.
Unlike Renwei, I'm not too worried about experimental options. I don't
think these are supposed to escape into the wider network, so we should
not let them drive our decision-making.
However, I do agree that it worrying to make this standards track. It
really does seem to be trying to define as mandatory an implementation
behavior that might reasonably be flexible for different reasons.
If the use of IP options in the core is sufficiently worrying, why not
disable them on the core routers?
If two IP packets carry different explicit paths in their options, why
should they not be directed to different (explicitly routed) LSPs to
conform to those routes even though they carry the same FEC?
There are plenty of questions like these and I don't feel that requiring
an LER to conform to some behavior is beneficial.
Additionally, will you also be specifying the correct behavior of an LSR
that receives an IP packet that carries options but that is not carried
by an LSP when the LSR believes the packet should be carried by an LSP?
Now, if you made the I-D advice with suitable warnings, I might take a
different view. This would be an Informational I-D not a BCP.
I would prefer more time to be spent discussing these ideas before the
working group decides to embrace this work.
Cheers,
Adrian
----- Original Message -----
From: "Renwei Li" <renweili at huawei.com>
To: "'David Smith (djsmith)'" djsmith at cisco.com; "'Loa Andersson'"
<loa at pi.nu>; <mpls at ietf.org>
Cc: "'Ross Callon'" <rcallon at juniper.net>; "'David Ward'"
<dward at cisco.com>
Sent: Monday, October 27, 2008 10:46 PM
Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
> Hi Dave,
>
> I understand that the crafted IP options may be exploited by malicious
> users
> to launch attacks, but some software vendors also develop their
software
> tools based on the options. The Class 2 options can't be simply
ignored.
>
> If an LER makes an IP packet un-routable because LSR doesn't install
BGP
> routes, the particular LER has an implementation problem.
>
> As I said before, if an IP packet has options inside, there has to be
some
> reasons for the options. Sometimes, if LER doesn't look at the
options,
> the
> packet can't be correctly forwarded. For example, if the packet wants
to
> be
> selectively broadcast to multiple destinations, the options must be
> examined.
>
> Moreover, IP options are also used for research and experiment. In
such
> cases, such experimental options are sometimes expected to be
processed at
> each hop.
>
> As suggested before, it could be a CLI knob to turn on/off the
feature.
>
> If you try to standardize the forwarding path in LER, you have to
consider
> all the possible IP options.
>
> Regards,
>
> Renwei
>
>
>
>> -----Original Message-----
>> From: David Smith (djsmith) [mailto:djsmith at cisco.com]
>> Sent: Friday, October 24, 2008 8:50 AM
>> To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
>> Cc: Ross Callon; David Ward
>> Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
>>
>>
>> Hi Renwei,
>>
>> Rather than a local LER implementation issue, I'd say this is really
a
>> LER "forwarding issue". And the MPLS WG has defined many standards on
>> "forwarding issues". Consider RFC3443 (TTL Processing in MPLS
Networks)
>> and RFC3270 (MPLS Support of DiffServ). Our draft complements RFC3443
>> and RFC3270.
>>
>> >Moreover, when an IP packet has an option, it usually has a
>> >reason for having such an option, and thus expects to be
>> >processed along the forwarding path in the network.
>>
>> Keep in mind one reason (used by an attacker) may simply be "DoS
LSRs".
>> While the attacker hopes the packet is processed along the forwarding
>> path, the MPLS network operator expects it to be tunnelled d by the WG.
Regards,
/dave
-----Original Message-----
From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of
Adrian Farrel
Sent: Monday, October 27, 2008 7:57 PM
To: mpls at ietf.org
Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
I too am a bit concerned about this draft.
Unlike Renwei, I'm not too worried about experimental options. I don't
think these are supposed to escape into the wider network, so we should
not let them drive our decision-making.
However, I do agree that it worrying to make this standards track. It
really does seem to be trying to define as mandatory an implementation
behavior that might reasonably be flexible for different reasons.
If the use of IP options in the core is sufficiently worrying, why not
disable them on the core routers?
If two IP packets carry different explicit paths in their options, why
should they not be directed to different (explicitly routed) LSPs to
conform to those routes even though they carry the same FEC?
There are plenty of questions like these and I don't feel that requiring
an LER to conform to some behavior is beneficial.
Additionally, will you also be specifying the correct behavior of an LSR
that receives an IP packet that carries options but that is not carried
by an LSP when the LSR believes the packet should be carried by an LSP?
Now, if you made the I-D advice with suitable warnings, I might take a
different view. This would be an Informational I-D not a BCP.
I would prefer more time to be spent discussing these ideas before the
working group decides to embrace this work.
Cheers,
Adrian
----- Original Message -----
From: "Renwei Li" <renweili at huawei.com>
To: "'David Smith (djsmith)'" djsmith at cisco.com; "'Loa Andersson'"
<loa at pi.nu>; <mpls at ietf.org>
Cc: "'Ross Callon'" <rcallon at juniper.net>; "'David Ward'"
<dward at cisco.com>
Sent: Monday, October 27, 2008 10:46 PM
Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
> Hi Dave,
>
> I understand that the crafted IP options may be exploited by malicious
> users
> to launch attacks, but some software vendors also develop their
software
> tools based on the options. The Class 2 options can't be simply
ignored.
>
> If an LER makes an IP packet un-routable because LSR doesn't install
BGP
> routes, the particular LER has an implementation problem.
>
> As I said before, if an IP packet has options inside, there has to be
some
> reasons for the options. Sometimes, if LER doesn't look at the
options,
> the
> packet can't be correctly forwarded. For example, if the packet wants
to
> be
> selectively broadcast to multiple destinations, the options must be
> examined.
>
> Moreover, IP options are also used for research and experiment. In
such
> cases, such experimental options are sometimes expected to be
processed at
> each hop.
>
> As suggested before, it could be a CLI knob to turn on/off the
feature.
>
> If you try to standardize the forwarding path in LER, you have to
consider
> all the possible IP options.
>
> Regards,
>
> Renwei
>
>
>
>> -----Original Message-----
>> From: David Smith (djsmith) [mailto:djsmith at cisco.com]
>> Sent: Friday, October 24, 2008 8:50 AM
>> To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
>> Cc: Ross Callon; David Ward
>> Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
>>
>>
>> Hi Renwei,
>>
>> Rather than a local LER implementation issue, I'd say this is really
a
>> LER "forwarding issue". And the MPLS WG has defined many standards on
>> "forwarding issues". Consider RFC3443 (TTL Processing in MPLS
Networks)
>> and RFC3270 (MPLS Support of DiffServ). Our draft complements RFC3443
>> and RFC3270.
>>
>> >Moreover, when an IP packet has an option, it usually has a
>> >reason for having such an option, and thus expects to be
>> >processed along the forwarding path in the network.
>>
>> Keep in mind one reason (used by an attacker) may simply be "DoS
LSRs".
>> While the attacker hopes the packet is processed along the forwarding
>> path, the MPLS network operator expects it to be tunnelled via an
LSP.
>>
>> >In this case, an ingress LER is essentially just one hop
>> >away from the exit LER. The processing of such options on
>> >LER should be no different from on other routers
>>
>> This is not true for IP option packets. For packets w/o IP options
this
>> is true because they are LSP tunnelled from ingress LER to egress
LER.
>> However, for packets "with" IP options this MAY not be true
(depending
>> upon the ingress LER implementation) because such option packets are
IP
>> routed downstream and NOT LSP tunneled.
>>
>> I'll argue this is a LER & LSR inter-op issue because the LSRs may
not
>> be carrying BGP routes and, if so, cannot route (unlabelled) transit
>> packets that were not MPLS encapsulated by the ingress LER.
>>
>> For these reasons, I think the MPLS WG needs a well-defined (ingress)
>> LER forwarding rule to mitigate the risk of IP option packets on MPLS
>> networks (ie, LSRs).
>>
>> Regards,
>>
>> /dave
>>
>>
>> -----Original Message-----
>> From: Renwei Li [mailto:renweili at huawei.com]
>> Sent: Thursday, October 23, 2008 10:10 PM
>> To: David Smith (djsmith); 'Loa Andersson'; mpls at ietf.org
>> Cc: 'Ross Callon'; 'David Ward'
>> Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
>>
>> Hi Dave,
>>
>> I do see your point. But it is really a local implementation issue.
With
>> or without it, LER would still work. It could at most serve as a CLI
>> knob which can be turned on or off according to whatever someone
wants,
>> but it doesn't look like a requirement for LER.
>>
>> > If so, should we not promote a consistent implementation among
vendor
>> > LERs via
>>
>> It depends on what you mean by "consistent implementation"? If it has
an
>> effect on inter-op for LERs from different vendors, no doubt we
should
>> promote it and I will fully support it. But if it doesn't have
anything
>> to do with inter-op, I am afraid we should not promote it. There are
so
>> many different LERs that have different local implementations inside,
>> but they are just fine provided they inter-op.
>>
>> Moreover, when an IP packet has an option, it usually has a reason
for
>> having such an option, and thus expects to be processed along the
>> forwarding path in the network. In this case, an ingress LER is
>> essentially just one hop away from the exit LER. The processing of
such
>> options on LER should be no different from on other routers.
>>
>> Regards,
>>
>> Renwei
>>
>>
>> > -----Original Message-----
>> > From: David Smith (djsmith) [mailto:djsmith at cisco.com]
>> > Sent: Thursday, October 23, 2008 7:17 AM
>> > To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
>> > Cc: Ross Callon; David Ward
>> > Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG
doc?
>> >
>> >
>> > Hi Renwei,
>> >
>> > Yes, it's a local LER decision.....but the LER implementation has
>> > consequences on downstream LSRs.
>> >
>> > Do you agree that failing to MPLS encapsulate a IPv4 packet simply
>> > because it has an IP option header may be a problem for the
downstream
>>
>> > network?
>> >
>> > If so, should we not promote a consistent implementation among
vendor
>> > LERs via an MPLS WG standard such that when an LER decides "whether
to
>>
>> > push an MPLS label stack onto an IP packet, the determination is
made
>> > without considering any IP options that may be carried in the IP
>> > packet header"??
>> >
>> > Regards,
>> >
>> > /dave
>> >
>> >
>> > -----Original Message-----
>> > From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
Behalf
>> > Of Renwei Li
>> > Sent: Thursday, October 23, 2008 1:38 AM
>> > To: 'Loa Andersson'; mpls at ietf.org
>> > Cc: 'Ross Callon'; 'David Ward'
>> > Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG
doc?
>> >
>> > Opposed.
>> >
>> > This draft imposes a new requirement on LER. But the new
requirement
>> > has nothing to do with inter-op. Moreover, the new requirement is
>> > really a matter of local implementation, and doesn't look really
like
>> a "MUST"
>> > requirement.
>> >
>> > Regards,
>> >
>> > Renwei
>> >
>> >
>> > > -----Original Message-----
>> > > From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
Behalf
>>
>> > > Of Loa Andersson
>> > > Sent: Tuesday, October 21, 2008 1:14 PM
>> > > To: mpls at ietf.org
>> > > Cc: Ross Callon; David Ward
>> > > Subject: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
>> > >
>> > > Working Group,
>> > >
>> > > we have been asked to adopt draft-dasmith-mpls-ip-options-01.txt
>> > > as a WG doc.
>> > >
>> > > This is to start a two week poll. Please send your comments on
>> > > whether
>> >
>> > > you think this is ready to become a wg document.
>> > >
>> > > George and Loa
>> > >
>> > > --
>> > > Loa Andersson
>> > >
>> > > Principal Networking Architect
>> > > Acreo AB phone: +46 8 632 77 14
>> > > Isafjordsgatan 22 mobile: +46 739 81 21 64
>> > > Kista, Sweden email: loa.andersson at acreo.se
>> > > loa at pi.nu
>> > > _______________________________________________
>> > > mpls mailing list
>> > > mpls at ietf.org
>> > > https://www.ietf.org/mailman/listinfo/mpls
>> >
>> >
>> > _______________________________________________
>> > mpls mailing list
>> > mpls at ietf.org
>> > https://www.ietf.org/mailman/listinfo/mpls
>>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
via an
LSP.
>>
>> >In this case, an ingress LER is essentially just one hop
>> >away from the exit LER. The processing of such options on
>> >LER should be no different from on other routers
>>
>> This is not true for IP option packets. For packets w/o IP options
this
>> is true because they are LSP tunnelled from ingress LER to egress
LER.
>> However, for packets "with" IP options this MAY not be true
(depending
>> upon the ingress LER implementation) because such option packets are
IP
>> routed downstream and NOT LSP tunneled.
>>
>> I'll argue this is a LER & LSR inter-op issue because the LSRs may
not
>> be carrying BGP routes and, if so, cannot route (unlabelled) transit
>> packets that were not MPLS encapsulated by the ingress LER.
>>
>> For these reasons, I think the MPLS WG needs a well-defined (ingress)
>> LER forwarding rule to mitigate the risk of IP option packets on MPLS
>> networks (ie, LSRs).
>>
>> Regards,
>>
>> /dave
>>
>>
>> -----Original Message-----
>> From: Renwei Li [mailto:renweili at huawei.com]
>> Sent: Thursday, October 23, 2008 10:10 PM
>> To: David Smith (djsmith); 'Loa Andersson'; mpls at ietf.org
>> Cc: 'Ross Callon'; 'David Ward'
>> Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
>>
>> Hi Dave,
>>
>> I do see your point. But it is really a local implementation issue.
With
>> or without it, LER would still work. It could at most serve as a CLI
>> knob which can be turned on or off according to whatever someone
wants,
>> but it doesn't look like a requirement for LER.
>>
>> > If so, should we not promote a consistent implementation among
vendor
>> > LERs via
>>
>> It depends on what you mean by "consistent implementation"? If it has
an
>> effect on inter-op for LERs from different vendors, no doubt we
should
>> promote it and I will fully support it. But if it doesn't have
anything
>> to do with inter-op, I am afraid we should not promote it. There are
so
>> many different LERs that have different local implementations inside,
>> but they are just fine provided they inter-op.
>>
>> Moreover, when an IP packet has an option, it usually has a reason
for
>> having such an option, and thus expects to be processed along the
>> forwarding path in the network. In this case, an ingress LER is
>> essentially just one hop away from the exit LER. The processing of
such
>> options on LER should be no different from on other routers.
>>
>> Regards,
>>
>> Renwei
>>
>>
>> > -----Original Message-----
>> > From: David Smith (djsmith) [mailto:djsmith at cisco.com]
>> > Sent: Thursday, October 23, 2008 7:17 AM
>> > To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
>> > Cc: Ross Callon; David Ward
>> > Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG
doc?
>> >
>> >
>> > Hi Renwei,
>> >
>> > Yes, it's a local LER decision.....but the LER implementation has
>> > consequences on downstream LSRs.
>> >
>> > Do you agree that failing to MPLS encapsulate a IPv4 packet simply
>> > because it has an IP option header may be a problem for the
downstream
>>
>> > network?
>> >
>> > If so, should we not promote a consistent implementation among
vendor
>> > LERs via an MPLS WG standard such that when an LER decides "whether
to
>>
>> > push an MPLS label stack onto an IP packet, the determination is
made
>> > without considering any IP options that may be carried in the IP
>> > packet header"??
>> >
>> > Regards,
>> >
>> > /dave
>> >
>> >
>> > -----Original Message-----
>> > From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
Behalf
>> > Of Renwei Li
>> > Sent: Thursday, October 23, 2008 1:38 AM
>> > To: 'Loa Andersson'; mpls at ietf.org
>> > Cc: 'Ross Callon'; 'David Ward'
>> > Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG
doc?
>> >
>> > Opposed.
>> >
>> > This draft imposes a new requirement on LER. But the new
requirement
>> > has nothing to do with inter-op. Moreover, the new requirement is
>> > really a matter of local implementation, and doesn't look really
like
>> a "MUST"
>> > requirement.
>> >
>> > Regards,
>> >
>> > Renwei
>> >
>> >
>> > > -----Original Message-----
>> > > From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On
Behalf
>>
>> > > Of Loa Andersson
>> > > Sent: Tuesday, October 21, 2008 1:14 PM
>> > > To: mpls at ietf.org
>> > > Cc: Ross Callon; David Ward
>> > > Subject: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
>> > >
>> > > Working Group,
>> > >
>> > > we have been asked to adopt draft-dasmith-mpls-ip-options-01.txt
>> > > as a WG doc.
>> > >
>> > > This is to start a two week poll. Please send your comments on
>> > > whether
>> >
>> > > you think this is ready to become a wg document.
>> > >
>> > > George and Loa
>> > >
>> > > --
>> > > Loa Andersson
>> > >
>> > > Principal Networking Architect
>> > > Acreo AB phone: +46 8 632 77 14
>> > > Isafjordsgatan 22 mobile: +46 739 81 21 64
>> > > Kista, Sweden email: loa.andersson at acreo.se
>> > > loa at pi.nu
>> > > _______________________________________________
>> > > mpls mailing list
>> > > mpls at ietf.org
>> > > https://www.ietf.org/mailman/listinfo/mpls
>> >
>> >
>> > _______________________________________________
>> > mpls mailing list
>> > mpls at ietf.org
>> > https://www.ietf.org/mailman/listinfo/mpls
>>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
