Draft multi6 agenda

This has been sent in, but of course we can still update it if necessary.
Please try to read all the drafts in advance.

    Brian + Kurtis
    multi6 co-chairs

Site Multihoming in IPv6 (multi6)

Tuesday, November 9 at 0900-1130
Wednesday, November 10 at 1530-1730
===================================

CHAIRS: Brian Carpenter <brc <at> zurich.ibm.com>
        Kurt Lindqvist <kurtis <at> kurtis.pp.se>

AGENDA:

  o Administrivia                                        5 minutes

  o Agenda Bashing                                       5 minutes

  o WG document status              (chairs)             5 minutes
    (extra time if significant Last Call or
     IESG issues arise)

     draft-ietf-multi6-multihoming-threats-01.txt      with IESG  
     draft-ietf-multi6-v4-multihoming-02.txt           WG Last Call ends Nov. 3
     draft-ietf-multi6-things-to-think-about-00.txt    WG Last Call ends Nov. 3
     draft-ietf-multi6-architecture-02.txt             WG Last Call ends Nov. 3

Reminder: multi6 WG Last Calls closing this Wednesday

Just a reminder that three WG Last Calls close on November 3.
This is your last chance to express agreement or disagreement
with these drafts being forwarded to the IESG.

So far we have had some useful comments on the second one, but
we'd like to hear more about the other two, if only "yes"!

draft-ietf-multi6-architecture-02.txt
draft-ietf-multi6-things-to-think-about-00.txt
draft-ietf-multi6-v4-multihoming-02.txt

    Brian + Kurtis
    multi6 co-chairs

Re: about draft-bagnulo-multi6dt-hba-00.txt

 In your previous mail you wrote:

   > But there is at least
   > another interpretation... BTW the encoding gives only a static (i.e.,
   > easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 
   > 05 00
   > 03 31 00 <48 octets> but please check  prefix.

   ok, i will try to clearify this

=> note that I've checked this...

   > Finally I am not convinced a type tag is not required for HBA CGAs, 
   > i.e.,
   > today HBA CGAs are not more usable than CGAs...

   i am not following this, could you expand a bit?

=> the question was about type tags for HBAs... finally I believe we
don't need them, i.e., HBAs which are not CGAs have no use of type tags,
HBAs which are CGAs are covered by the CGA document
(draft-ietf-send-cga-06.txt).

> PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and
> check/sign/verify). I can send it to who'd like to extend it to HBA
> (I'm using the standard BSD licence). It should be easy because if I've
> understood the design the multi-prefix extension is an extension field?

   we are planning to implement HBA, so this would be really helpful.
   I will contact you later.

Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt

Brian E Carpenter wrote:

>> You're right in the general case. However, one could further constrain 
>> flow label allocation for the hosts that implement multi6 so that for 
>> multi6 packets the receiver wouldn't have to compare the locators but 
>> only use the flow label. 
> 
> 
> No, that doesn't work, because two quite independent source hosts might
> choose the same flow label. You have no choice but to look at the source
> locator as well as the label.

It would work with the proper constraints. If some future standard where 
to say that a host should not send a multi6 packet unless the flow label 
had been "approved" (or allocated) by the intended receiver, the 
receiver could ensure that the flows of multi6 packets it receives each 
have a different flow label.
Whether we want to do this is a different point (and I don't think we 
should be overloading the flow label at all).

> Well, I think you could reasonably require that a sender never uses the 
> same
> flow label twice at the same time (that is more constraining than the 
> global
> rule, but probably not a problem in a 20 bit space).

Yes, and "same time" needs to take into account how long multi6 state is 
allowed to remain on a receiver.

> But you don't need to.

Some comments on draft-ietf-multi6-v4-multihoming-02.txt

Dear all,

This is the 1st time I read this draft, and, to be honest, I don't
really understand the value of the document. IMHO, more text and details
would help to fully meet the objectives of the draft. But I don't have
any suggestions besides the following (mostly) editorial comments.

- A table of contents is missing

Introduction

- a sentence detailing the structure of the document (from section 2
till end) would help.

- particularly, the abstract nor the introduction give me a hint of the
content of section 5. 

Section 2:

- all terms but one (mullti-addressed) are defined in RFC3582, why not
saying it ? (I'm OK with repeating the definitions, though)

Section 4.3

- I don't get the meaning of "having their upstreams remove those on
announcement".  Their upstreams what ? The same occurs in orher parts of
the text.

Section 5

Re: Some comments on draft-ietf-multi6-v4-multihoming-02.txt

Thierry,

The purpose of the document (which is one of our chartered
deliverables) is only to write down existing practice.
But I don't think any of us believe that has enough value to
actually add more text and details (i.e. do more work .

Thanks for the comments.

    Brian

Thierry Ernst wrote:
> Dear all,
> 
> This is the 1st time I read this draft, and, to be honest, I don't
> really understand the value of the document. IMHO, more text and details
> would help to fully meet the objectives of the draft. But I don't have
> any suggestions besides the following (mostly) editorial comments.
> 
> 
> - A table of contents is missing
> 
> 
> Introduction
> 
> - a sentence detailing the structure of the document (from section 2
> till end) would help.
> 
> - particularly, the abstract nor the introduction give me a hint of the
> content of section 5. 

Few comments on draft-ietf-multi6-architecture-02

Dear all,

Here are a few comments on draft-ietf-multi6-architecture-02

Section 2.
- Figure 1. only shows a site with 2 transit providers A and B. Wouldn't
it be useful to illustrate the case where the network is
"multi-attached" ? Then, wouldn't be useful to state if this draft
considers this specific case or not ? 

- What is the definition of "seamlessly supported" ? My mobility
background may not help me to undertand this term in the same way as it
is assumed in this document. I would use "Transparency". It's probably a
good idea to uniformize the terms between the mobility and the
multihoming fields, given the many identical issues.

Section 4.1:
- typo "remote domain domains"

- why the number 10**7 is used, and not, say, 10**10 ? Can we consider
the network everyone will have at home a site ? Such network would most
likely be multihomed to distinct ISPs.

Section 4.2
- I would add NEMO Basic Support (draft-ietf-nemo-basic-support-03.txt,
together with MIP6 (although there is no Route Optimization procedure in
NEMO Basic Support).

  [BTW, just being curious, can't we consider a NEMO multihomed to 2

Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt

Dear all,

About mobility, something that I would like to add in the draft in
section 2.4 and/or section 6.6:

- In 2.4: I'm wondering here again if mentioning MIP6 without mentioning
NEMO Basic Support is sufficient. A mobile network as defined in the
NEMO WG may benefit from the work done in multi6. Reversely, the work
done by the NEMO WG may benefit to MULTI6 (if the mobility-support
approach path is followed by the Multi6 group).

- In 6.5: I would request to add "NEMO sites" (ad-hoc sites is currently
mentioned, but not NEMO sites). Also, I think it's a good idea to add
"nested-NEMO sites". Since this document is about "things to think
about", it wouldn't hurt to these 2.

Thierry.

Scribes needed!

Just a reminder that we need a volunteer to take minutes and a couple
of volunteers to act as jabber scribes, for the two multi6 sessions
next week.

    Brian

Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt

marcelo bagnulo braun wrote:
>>> Good news. This is wrong (and I didn't realise it when analyzing NOID).
>>> Flow Labels are not unique on their own and cannot be used for
>>> anything on their own. You must always lookup a 3tuple.But if the
>>> received  {Flow Label, Source Locator, Dest Locator} is in the set
>>> {Flow Label, {Source Locators}, {Dest Locators}} corresponding to
>>> a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim
>>> *knows* that it is a multi6 packet.
>>
>>
>> If the {flow label, src locator, dst locator} is used to identify the 
>> state then you are right. But that prevents a possible optimization 
>> with changing locator sets (think mobility) by requiring that multi6 
>> signaling be complete to tell the peer of the new locator before that 
>> locator can be used as the source.
>>
> 
> well, but in this case, there is also some security information nneded 
> to authenticate the new locator, so the receiver will have additional 
> information for the demux of this packet i guess.

Exactly. I'm kind of assuming we have something like HBA in place,
so prior knowledge of all locators is needed anyway.

    Brian