Subject: RE: [PWE3] PWE3 IANA policy

From: Shahram Davari <[email-masked]>
Date: Thu, 21 Jul 2005 08:02:57 -0700

Sasha,

Y.1711 OAM label being the bottom label is only processed by an Egress LER  and is transparent to all other LSRs in an LSP. If the egress LER doesn't understand this
label it will drop the packet, which is not a big deal, and nothing bad would happen.

Let's take this off-line if you like, since the details are not relevant to this
thread.

Thanks,
Shahram

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Thursday, July 21, 2005 5:45 AM
> To: Shahram Davari
> Cc: [email-masked]; [email-masked]'
> Subject: RE: [PWE3] PWE3 IANA policy 
> 
> 
> Shahram and all,
> Sorry for a belated response, but...
> 
> IMHO there is a substantial difference between allocation
> of a new reserved label and allocation of a new PW Type:
> 
> - The former (especially so in the case of the Y.1711 OAM Label)
>   potentailly affects ALL the LSRs receiving packets with the label 
>   stack containing this label. The standard treatment
>   of unknown looked at labels is to discard the packets so labeled,
>   and since it is impossible to know whether some LSR on the LSP
>   shall ever look at the OAM label or not, the result of
>   placing such a label in the stack could be quite unexpected
>   for the sender. Hence an explicit description of some alternative 
>   action was justly required
> 
> - The latter only affects the Targeted LDP peers negotiating setup of
>   a specific PW. If one of them does not recognize the PW type
>   present in the PWId FEC distributed by the other, it will
>   simply release the label bound to this FEC, and the PW shall
>   not be ever set up. But then, you could hardly expect anything 
>   else, right? I.e., the consequences here are fully predicatble
>   and the effect limited. IMHO this means that the only thing
>   you need in such a case is unique allocation. FCFS definitely
>   meets this requirement.
> 
> 
> Regards,
> 			Sasha
> > -----Original Message-----
> > From: Shahram Davari [mailto:[email-masked]]
> > Sent: Wednesday, July 20, 2005 6:10 PM
> > To: [email-masked]'
> > Cc: Sasha Vainshtein; [email-masked]
> > Subject: RE: [PWE3] PWE3 IANA policy 
> > 
> > 
> > All I meant by this example was that there is a precedence 
> > for requiring an RFC.
> > Informational/experimental RFC's don't need to be approved by 
> > IETF WGs.
> > That's my proposal. Please debate this if you like.
> > 
> > Yours,
> > Shahram
> > 
> > > -----Original Message-----
> > > From: Eric Rosen [mailto:[email-masked]]
> > > Sent: Wednesday, July 20, 2005 12:03 PM
> > > To: Shahram Davari
> > > Cc: 'Sasha Vainshtein'; [email-masked]
> > > Subject: Re: [PWE3] PWE3 IANA policy 
> > > 
> > > 
> > > 
> > > > I  could remind you  of the  MPLS OAM  Alert label  that 
> > > was  requested by
> > > > ITU. IETF's response  was to that an Informational RFC  is 
> > > needed in order
> > > > to get that label assigned.
> > > 
> > > RFC  3032 states  that IANA  may assign  such label  values, 
> > > "based  on IETF
> > > consensus".  RFC 2424  defines  "IETF  Consensus" in  this  
> > > context as  "new
> > > assignments  are made  via  RFCs approved  by  the IESG".   
> > > We could  debate
> > > whether the IESG acted properly  in allowing this particular 
> > > assignment, but
> > > clearly the IANA  considerations for this 4-bit space  call 
> > > for review.  And
> > > the  policy is  NOT  simply "publish  an  RFC and  you  
> > > automatically get  a
> > > number". 
> > > 
> > > So basically this  is irrelevant to the current discussion.   
> > > No one has yet
> > > suggested "IETF consensus" as the policy. 
> > > 
> > 
> 

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

---

From: Alex Zinin <[email-masked]>
Date: Thu, 21 Jul 2005 13:34:21 -0700

OK, a fresh eye here.

It's clear that PW type exhaustion can be addressed with reserving part of
the space for future use. Don't think anyone would have a problem with
this.

On the remaining part, let's step back a little. The question here is which
of the two you guys want to optimize for:

  a) Freedom of invention  OR
  b) Sanity checking via review

Given the transport nature of a PW, case a) is similar to TCP/UDP port
numbers: folks want to do something on their own--sure, ask for a number to
not clash with other experiments and go on; folks want to interoperate--
sure, ask for a number and work on an IETF standard. FCFS would do that.
Considerations: SPs don't benefit from sanity checking, potential
proliferation of proprietary solutions, other SDOs can work on their
versions of PWs.

Case b) would result in a more controlled technology development and could
be done with a number of policies, expert review being the most flexible
one. Considerations: someone will have to see some level of details of new
developments in this area, and some may consider this sensitive
information. I consider other things like long delays, biased reviewer etc.
a bug that can be dealt with and wouldn't optimize for it.

Accept the fact that you won't get the perfect solution, and pick one of
the two optimization targets above.

Regarding the specific proposal of FCFS + I-D. I think it does not solve
any problem--don't expect IANA to check more than just existence of an ID,
which is no better than giving a one line description directly to IANA, and
it encourages publication of unnecessary documents.

-- 
Alex

---

From: Eric Rosen <[email-masked]>
Date: Fri, 22 Jul 2005 14:21:24 -0400

I disagree with one aspect of your statement:

        "I consider other things like long delays, biased reviewer etc.
         a bug that can be dealt with and wouldn't optimize for it." 

Experience in a wide variety of settings (including, but not limited to, the
IETF), shows that no matter how  well-intended a process is, the process can
be deflected from its intended goal by politics and bureaucracy.  This isn't
a "bug"  that creeps  in unexpectedly, it  is an inherent  characteristic of
process, and it is something that is to be expected. 

That's why  process A is  usually associated with  a second process  B whose
purpose  is to  allow  the reversal  of  process A.   ("Don't  worry if  the
reviewer turns  you down because he  works for one of  your competitors, you
can appeal to the IESG.  Don't worry if the IESG turns you down because they
are resistant  to unorthodox ideas, you  can appeal to the  IAB.  Just fill
out these forms in triplicate and wait six years.") 

So  if  you are  considering  a process  which  provides  "sanity by  expert
review", you can't defend it just  by saying "review is good", you also have
to take into account the likelihood  that the process will be delayed and/or
deflected by  bureaucratic and/or political considerations.   Of course, the
folks in charge of running the process never take this seriously, and always
insist that  everything is working  fine, or at  least will be  working fine
starting tomorrow, after the last bug is removed.

On the purported disadvantages of "freedom":

- SPs don't benefit from sanity checking

  This is a little overstated, it would be more accurate to say "SPs are not
  forced to await the results of the IETF processes".  Of course, if you put
  it that way, it doesn't sound so bad ;-)

- Potential proliferation of proprietary solutions,

  Actual  marketplace  competition  before  a  single  standard  is  chosen?
  Heavens. 

  Note  also  that  "sanity  checking"  does not  prevent  proliferation  of
  standard solutions, as we certainly know in the MPLS-related areas. 

- other SDOs can work on their versions of PWs. 

  And why shouldn't they? 

> any problem

On the contrary, it solved the  problem of finding something to which the WG
could agree ;-)