Hi Wendy,
so the conclusion is:
at the end of section 5.2.1 of draft-ietf-alto-protocol-20.txt,
we REMOVE
- Each endpoint MUST map into exactly one PID. Since longest-prefix
- matching is used to map an endpoint to a PID, this can be
- accomplished by ensuring that no two PIDs contain an identical IP
- prefix.
and ADD instead
+ A network map MUST NOT define two or more PIDs that contain
+ an identical IP prefix, in order to ensure that the longest-prefix
+ matching algorithm maps each endpoint into exactly one PID.
+
+ If an ALTO client receives an invalid network map defining two or
+ more PIDs that contain an identical IP prefix, the ALTO client
+ SHOULD completely ignore the whole network map.
OK? I support this change.
Do you think we should add another paragraph saying that
MapA: A1 = 10.0.0.0/15
A2 = 10.0.0.0/16, 10.1.0.0/16
is legal, and 10.0.0.1 should be in A2
? I don't think that this is neccesssary but I won't object against
adding an explicit statement.
What do you think?
Thanks
Sebastian
On Mon, Nov 04, 2013 at 09:18:15AM -0500, Wendy Roome wrote:
> Actually I'm in favor or the second alternative for #2 -- ignore the map
> altogether:
>
> > If an ALTO client receives an invalid network map defining two or
> > more PIDs that contain an identical IP prefix, the ALTO client
> > SHOULD completely ignore the complete network map.
>
>
> Sorry for the confusion! I thought that was #3.
>
> - Wendy
>
>
> On 11/01/2013 15:56, "Sebastian Kiesel" <[email protected]> wrote:
>
> >Hi Wendy,
> >
> >so you are saying that for issue 2) we should go with the second
> >text proposal? I don't have strong feelings about that.
> >
> >What about 3) ? Do you want to propose text? Or should we go without
> >a clarification?
> >
> >Thanks
> >Sebastian
> >
> >On Fri, Nov 01, 2013 at 04:27:30PM -0400, Wendy Roome wrote:
> >> I don't like saying that the client should just ignore all occurrences
> >>of
> >> a duplicate CIDR. I think that if the server created a map with
> >>duplicate
> >> CIDRs, the server has a major problem, and I wouldn't trust that server.
> >>
> >> After all, even if a server automatically creates the network map from
> >> network data, how hard would it be for the server to test for and remove
> >> duplicates? Especially because we expect the client to be smart enough
> >>to
> >> detect duplicates??
> >>
> >> There's an old saying: If you add a teaspoon of excrement to a barrel of
> >> fine wine, you have a barrel of excrement. If a network map has
> >>duplicate
> >> CIDRs, I think that network map is junk.
> >>
> >>
> >> - Wendy Roome
> >>
> >> On 11/01/2013 15:13, "Sebastian Kiesel" <[email protected]> wrote:
> >>
> >> >Dear all,
> >> >
> >> >
> >> >Let's focus on IP prefixes in PID definitions as this has to be
> >> >clarified before the protocol document can be finalized.
> >> >In other words we are talking about section 5.2.1 of
> >> >draft-ietf-alto-protocol-20.txt.
> >> >
> >> >
> >> >it seems that we could not agree on a tiebreaker algorithm to be
> >> >used by the client if it receives a network map defining multiple
> >> >PIDs each containing the same IP prefix.
> >> >
> >> >
> >> >
> >> >Let me try to summarize with two examples:
> >> >
> >> >MapA: A1 = 10.0.0.0/15
> >> > A2 = 10.0.0.0/16, 10.1.0.0/16
> >> >
> >> >is legal, and 10.0.0.1 should be in A2
> >> >
> >> >this is what follows from the current specification, though it may
> >> >be surprising to some of us.
> >> >
> >> >
> >> >MapB: B1 = 10.0.0.0/15
> >> > B2 = 10.0.0.0/15, 192.168.0.0/16
> >> >
> >> >is NOT legal.
> >> >
> >> >
> >> >
> >> >So my proposal to move forward:
> >> >
> >> >1. clarify that this kind of map as in example B is illegal:
> >> >
> >> >In Sec. 5.2.1:
> >> >
> >> >Old:
> >> >
> >> > Each endpoint MUST map into exactly one PID. Since longest-prefix
> >> > matching is used to map an endpoint to a PID, this can be
> >> > accomplished by ensuring that no two PIDs contain an identical IP
> >> > prefix.
> >> >
> >> >Replace with:
> >> >
> >> > A network map MUST NOT define two or more PIDs that contain
> >> > an identical IP prefix, in order to ensure that the longest-prefix
> >> >
> >> > matching algorithm maps each endpoint into exactly one PID.
> >> >
> >> >
> >> >
> >> >
> >> >2. optional: specify client behavior in this error condition
> >> >
> >> >Append a sentence at the end of 5.2.1.
> >> >
> >> > If an ALTO client receives an invalid network map defining two or
> >> > more PIDs that contain an identical IP prefix, the ALTO client
> >> > SHOULD ignore that prefix and behave as if the prefix did not occur
> >> > in any PID definition.
> >> >
> >> >or:
> >> >
> >> > If an ALTO client receives an invalid network map defining two or
> >> > more PIDs that contain an identical IP prefix, the ALTO client
> >> > SHOULD completely ignore the complete network map.
> >> >
> >> >
> >> >
> >> >3. optional: add a clarification that example A above is legal and A2
> >> >is the result.
> >> >
> >> >
> >> >
> >> >
> >> >I think that we should add 1) and the first text proposal for 2).
> >> >I don't think that we need 3) but I will not object if someone
> >> >comes up with a good text proposal.
> >> >
> >> >
> >> >
> >> >Comments?
> >> >
> >> >Thanks
> >> >Sebastian
> >>
> >>
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
