Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt

["Susan Hares" <[e-mail]>]

Warren:

In my conversation with John yesterday, he said he would revise this in real
soon (~1 wks) so we could do a WG LC.  Hopefully - we've got this version
captures all the issues.  I'm looking for a reviewers of the next version to
post to the list.  Can I sign you up? 

Sue  

-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of Warren Kumari
Sent: Friday, August 29, 2014 1:14 PM
To: John G. Scudder
Cc: idr@ietf. org; [e-mail]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-12.txt

'm checking to see if there has been any progress on this -- last I remember
was that John had a few comments to incorporate (below)....


We have a document form 2012 that is stuck in MISSREF state on this document
(below)  -- wondering if we should try rewrite the relevant bit to no longer
reference this...


W

2012-09-17 draft-ietf-idr-as0-06.txt [C171]
MISSREF*R(1G)
REF draft-ietf-idr-error-handling NOT-RECEIVED W. Kumari, R. Bush, H.
Schiller, K. Patel "Codification of AS 0 processing"
Bytes: 12085
Working Group: Inter-Domain Routing



On Fri, Jun 13, 2014 at 1:03 PM, John G. Scudder <[e-mail]> wrote:
> Eric,
>
> On Jun 13, 2014, at 12:03 PM, Eric Rosen <[e-mail]> wrote:
>
>> I wonder if the first two bullet items of Section 7.11 should be 
>> slightly revised (and perhaps expanded to three items), as follows:
>>
>>   o If the Next Hop field contains an IPv4 address (possibly as a
>>     sub-field), the field SHOULD be considered invalid if the IPv4
address
>>     appears in the "IANA IPv4 Special-Purpose Address Registry"
[IANA-IPV4]
>>     and either the "destination" or the "forwardable" boolean in that
>>     registry is given as "false".
>>
>>   o If the Next Hop field contains an IPv6 address (possibly as a
>>     sub-field), the field SHOULD be considered invalid if the IPv6
address
>>     appears in the "IANA IPv6 Special-Purpose Address Registry"
>>     [IANA-IPV6], the address is not an IPv4-mapped IPv6 address, and
either
>>     the "destination" or the "forwardable" boolean in that registry is
>>     given as "false".
>>
>>   o If the Next Hop field contains an IPv4-mapped IPv6 address (possibly
as
>>     a sub-field), the field SHOULD be considered invalid unless the use
of
>>     such addresses has been explicitly allowed for the particular
AFI/SAFI
>>     that occurs in this MP_REACH_NLRI attribute.  (E.g., see RFC 4659 and
>>     RFC 4798.)
>>
>> This would cover the 6PE and 6vPE cases, and would also cover the 
>> cases where the next hop field contains an RD followed by an IP address.
>
> Thanks. This looks good. Barring further discussion, I'll plan to
incorporate your text into -13.
>
>> John> Another alternative, if it gets too hairy to spec this, would 
>> John> be to back the changes out. I don't know how the rest of the WG 
>> John> would feel about that.
>>
>> That's also a possibility.  The IANA special-purpose address 
>> registries really seem to be focused on the use of addresses in the 
>> data plane rather than the control plane; it's not obvious that the 
>> content of those registries should affect the control plane.  Are we 
>> sure that there are no deployments (other than 6PE and 6vPE 
>> deployments) that use IP special-purpose addresses as (part of) the Next
Hop field?
>
> No, I'm not sure, although the reasoning in citing the registry was that
if the address is non-forwardable, how do you expect to use it as a next
hop? You're right that this seems like an perversion of the registry's
original purpose. However the options I could see came down to:
>
> - Cite the registries as I've done,
> - Find a better citation -- I looked and didn't find anything,
> - Define "invalid IP host address" from the ground up -- seemed like a 
> terrible idea to do in this document, or
> - Ignore the issue as in earlier versions of the draft.
>
> Of these, citing the registries seemed less terrible than the
alternatives. I'm certainly open to proposals on how to improve. I guess we
could explicitly acknowledge that it's underspecified and invite interested
parties to write a spec to properly define "invalid IP host address",
without trying to actually fix it in this document. The question comes down
to whether the current text helps more than it hurts. I'm inclined to think
that it does, but then I would, wouldn't I?
>
>>>  "Certain address families, for example MVPN [RFC7117] and EVPN  
>>> [I-D.ietf-l2vpn-evpn] have NLRI that are typed."
>>>
>>> I believe the first reference is supposed to be either "MCAST-VPN
[RFC6514]"
>>> or "MCAST-VPLS [RFC7117]", or perhaps both.
>>
>> OK, thanks. I'll address this in the next rev.
>>
>> Eric> If information about the TE path attribute is blocking the 
>> Eric> progress of the error handling draft, please consider advancing 
>> Eric> the draft without that information.
>>
>> John> While I'd be overjoyed to RFC this thing and move on, off-hand 
>> John> I can't think of a justification for singling the TE path 
>> John> attribute out as not needing to be updated. I'd be pleased to 
>> John> be provided with one, though.
>>
>> Well, let me quote from some previous messages regarding this draft:
>>
>>      "Of course we could continue error-handling as a seemingly eternal
>>      draft, but I think there is some value in saying "close enough" and
>>      graduating it to RFC, especially for implementors that are less
>>      steeped in the WG and don't necessarily have the background to
>>      distinguish between Internet Drafts that are really *drafts* and
those
>>      that are de-facto standards."
>>
>>      "The draft does try to strike a balance between prudence and
avoidance
>>      of ever-mounting complexity of error-detection heuristics to attempt
>>      to detect ever less-likely problems."
>>
>> These sentiments seem very wise, and I think the draft has been 
>> around long enough for use to say that anything not incorporated yet is
"out of scope"
>> and will have to be covered in future documents.
>
> Well-played.
>
> I'm OK with that approach. I'd like to invite anyone who feels we MUST
have coverage of the TE path attribute before publishing error-handing, to
propose text. Otherwise, I'll replace the section with something like:
>
> 7.13.  Traffic Engineering path attribute
>
>    We note that [RFC5543] does not detail what constitutes
>    "malformation" for the Traffic Engineering path attribute.  A future
>    update to that specification may provide more guidance.  In the
>    interim, an implementation that determines (for whatever reason) that
>    an UPDATE message contains a malformed Traffic Engineering path
>    attribute MUST handle it using the approach of "treat-as-withdraw".
>
> One final point to discuss is whether the proper approach is
"treat-as-withdraw" or if "attribute discard" would be OK in this case.
>
> Thanks,
>
> --John
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr



--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr