Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?

[Eric Rosen <erosen at cisco.com>]

I believe this draft is meant to solve a very simple problem.

It  has been observed  that there  are MPLS  implementations which  will not
encapsulate IP packets that have options.  

In many  environments, this behavior  is undesirable.  However, it  has been
observed that there  are some implementations in which  this behavior cannot
be shut off.

The draft  attempts to  avoid this  situation in the  future by  setting two
rules:

1. It  must be possible  to configure  an LER such  that it will  apply MPLS
   encapsulation irrespective of the presence of IP options.

2. This configuration setting is the default.

However,  the draft  also specifies  that  this is  not meant  to alter  the
processing of control protocols such as RSVP which may use IP options.

So I see basically two grounds on which this draft may be opposed:

- One might think it is perfectly  okay to have an MPLS implementation which
  cannot be configured to label packets that have IP options.

  This doesn't seem reasonable to me.

- One might  think that  the labeling  of a packet  with options  should not
  necessarily be the default behavior.

  This seems more  more reasonable, at least in  theory.  However, given the
  fact that IP  options have been in disrepute for  several decades, I don't
  really see that there's any problem caused by making this the default.

Adrian> It  really  does  seem  to  be  trying to  define  as  mandatory  an
Adrian> implementation  behavior  that  might  reasonably  be  flexible  for
Adrian> different reasons. 

I  think  the  intent  is  only  to define  the  behavior  as  mandatory  to
implement, not to prohibit the flexibility.

Adrian> If the use  of IP options in the core  is sufficiently worrying, why
Adrian> not disable them on the core routers?

I think that's  usually done, but I don't  see what that has to  do with the
fact that an LER may have refused to label a packet with options.

Adrian> If two IP  packets carry different explicit paths  in their options,
Adrian> why  should they not  be directed  to different  (explicitly routed)
Adrian> LSPs to conform to those routes even though they carry the same FEC?

This behavior  is not ruled  out if some  network wants to  support explicit
routing via IP  options.  Since the percentage of  service provider networks
that support  this is, err, low,  I don't think  it can be argued  that this
should be the default behavior.

Renwei> This draft imposes a new requirement on LER. But the new requirement
Renwei> has nothing to do with inter-op.

If some  router implementation  cannot label IP  packets that  have options,
then that implementation cannot operate as an LER in certain environments.  

Renwei> It could at most  serve as a CLI knob which can  be turned on or off
Renwei> according to whatever someone wants, 

All the draft does is make the CLI knob (and its default setting) mandatory.

Renwei> Moreover, when an  IP packet has an option, it  usually has a reason
Renwei> for having  such an option, and  thus expects to  be processed along
Renwei> the forwarding path in the network

I can't say what expectations the creator of such a packet may have had, but
if he  really expected  special processing all  along the path  through some
arbitrary network, then  he's expecting a practice which  hasn't been common
since the early days of the Internet.

Renwei> Some software vendors also develop their software tools based on the
Renwei> options 

The draft is really concerned with data packets, and isn't meant to prohibit
the use of IP options on  the control/monitoring protocols which are used in
a particular network environment.






_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls