Subject: Re: [mpls] LDP IPv6

From: "Bin Mo (bmo)" <[email-masked]>
Date: Tue, 10 Aug 2010 10:21:48 -0500

Hi Vishwas,

I have couple of questions on draft-manral-mpls-ldp-ipv6-03.

1. In section 3 LSP mapping, is IPv4 hello adjacency on an interface required to forward labeled IPv4 traffic to nexthop, and IPv6 hello adjacency required to forward labeled IPv6 traffic?

2. In section 6.1 transport connection establishment, if both IPv4 and IPv6 transport addresses are available, any preference which transport address should be preferred?

Thanks

/Bin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vishwas Manral
> Sent: Monday, July 26, 2010 5:39 PM
> To: George Swallow (swallow); Loa Andersson
> Cc: Rob Shakir; [email-masked]; [email-masked]
> Subject: [mpls] LDP IPv6
> 
> Hi Chairs,
> 
> We would like to request you to have a WG call to gauge support and
> adopt the document LDP IPv6 as a working Group item.
> 
> The document is located at
> http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03
> 
> The document in the past has got some review on the list.
> 
> Thanks,
> Vishwas
> 
> On Fri, Apr 16, 2010 at 6:59 AM, Vishwas Manral
> <[email-masked]> wrote:
> > Hi Egor,
> >
> > 1. As Mikael brought out the question of what else is missing I
> > brought up the MIB and RSVP-TE issues. I will bring the details out
> in
> > another mail with the correct subject line.
> > 2. I guess now that we have more knowledge of the draft we can
> > actually try to push it further.
> >
> > Thanks,
> > Vishwas
> >
> > On Fri, Apr 16, 2010 at 1:03 AM, Egor Zimin <[email-masked]> wrote:
> >> Hi, Vishwas,
> >>
> >> 1. About RSVP-TE and IPv6 Router Alert option.
> >> I do not quite understand your opinion.
> >> Do you propose to remove Router Alert option for IPv6 ? Why ?
> Because of
> >> lack of RSVP-TE IPv6 implementations alone ? Because of only RSVP TE
> uses
> >> this option ? Also, what security issues do you mean ?
> >> And... what does that have to LDPv6 draft discussion?
> >>
> >> 2. About draft-manral-mpls-ldp-ipv6-03:
> >> I think, the changes and clarifications proposed in the draft are
> very
> >> obvious and not so significant. In fact, the draft only clarifies
> peer
> >> discovery and transport session establishment procedures for IPv6. I
> don't
> >> understand why this draft has not yet become RFC.
> >>
> >> 2010/4/15 Vishwas Manral <[email-masked]>
> >>>
> >>> Hi Mikael/ Rob/ Farhan/ Egor,
> >>>
> >>> > Considering IPv4 runout I definitely see greenfield rollout in 1-
> 2
> >>> > years wanting to do this IPv6 only, and considering code usually
> >>> > takes time to be finished the standards should definitely be done
> >>> > by now.
> >>> >
> >>> > What else is missing?
> >>> Let me begin by saying that most drafts/ RFC's have some IPv6
> >>> component to them. This however is appended as an add-on in some
> >>> cases. As most of these have not been looked at in detail there are
> >>> some holes in the RFC for IPv6.
> >>>
> >>> I found similar holes a couple of years back and wrote this and the
> >>> MPLS-TC IPv6 MIB draft. I also noticed that for RSVP-TE for IPv6 we
> do
> >>> not have support for Router Alert in a lot of platforms. It also
> has
> >>> all the security issues aside from that.
> >>>
> >>> As RSVP-TE seems to be carrying Router Alert as a legacy thing and
> as
> >>> RSVP-TE IPv6 is not implemented on the field I think it would be
> good
> >>> to do away, remove the use of Router Alert in RSVP for IPv6.
> >>>
> >>> What do folks on the list think?
> >>>
> >>> BTW, I had mails from a couple of more operators in private and
> have
> >>> forwarded them to the chairs.
> >>>
> >>> Thanks,
> >>> Vishwas
> >>>
> >>> On Wed, Apr 14, 2010 at 11:01 PM, Mikael Abrahamsson
> <[email-masked]>
> >>> wrote:
> >>> > On Wed, 14 Apr 2010, Rob Shakir wrote:
> >>> >
> >>> >> I'd just like to speak up in support of this draft also. As an
> operator
> >>> >> that is progressing an IPv6 rollout, we are finding that in a
> number of
> >>> >> places, the only need to utilise 6PE is in order to address the
> lack of
> >>> >> support for IPv6 in LDP.
> >>> >
> >>> > +1 from me as well, I'm actually surprised that there hasn't been
> more
> >>> > work
> >>> > in establishing feature parity between IPv4 and IPv6 in the
> control
> >>> > plane.
> >>> > I'd imagine that by now it would be possible to implement
> >>> > standards-based
> >>> > IPv6 only control plane with equal functionality as is today
> possible
> >>> > with
> >>> > IPv4.
> >>> >
> >>> >> Whilst I think it's unlikely that many operators are currently
> putting
> >>> >> this down as a mandatory requirement, it's definitely something
> that I
> >>> >> believe is required.
> >>> >
> >>> > Considering IPv4 runout I definitely see greenfield rollout in 1-
> 2 years
> >>> > wanting to do this IPv6 only, and considering code usually takes
> time to
> >>> > be
> >>> > finished the standards should definitely be done by now.
> >>> >
> >>> > What else is missing?
> >>> >
> >>> > --
> >>> > Mikael Abrahamsson    email: [email-masked]
> >>> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Egor Zimin
> >>
> >
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Bin Mo (bmo)" <[email-masked]>
Date: Tue, 10 Aug 2010 15:38:35 -0500

Hi Vishwas,

Thanks

/Bin

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 11 Aug 2010 21:38:08 -0700

Hi Bin,

Thanks for the thoughtful points you have brought up.
> 1. In section 3 LSP mapping, is IPv4 hello adjacency on an interface required to forward labeled IPv4 traffic to nexthop, and IPv6 hello adjacency required to forward labeled IPv6 traffic?

VM> Yes.

> 2. In section 6.1 transport connection establishment, if both IPv4 and IPv6 transport addresses are available, any preference which transport address should be preferred?
VM> The preference can be local and is based on which transport
session is established first.

Do let me know if this answers your questions?

Thanks,
Vishwas

---

From: "Bin Mo (bmo)" <[email-masked]>
Date: Thu, 12 Aug 2010 10:43:28 -0500

Hi Vishwas,

Thanks for your response. Please see my follow-up inline.

> > 1. In section 3 LSP mapping, is IPv4 hello adjacency on an interface
> required to forward labeled IPv4 traffic to nexthop, and IPv6 hello
> adjacency required to forward labeled IPv6 traffic?
> 
> VM> Yes.
[bmo] OK. The current text doesn't make this requirement clear (at least to me).
> 
> > 2. In section 6.1 transport connection establishment, if both IPv4
> and IPv6 transport addresses are available, any preference which
> transport address should be preferred?
[bmo]
Sounds good. There may be situations, however, where the session will not
be easy to establish.
RFC5036 says in session setup, one LSR plays passive role and the other plays
active role. For example, If based on the address, one LSR should play passive
role in IPv4 TCP connection and it aborts IPv6 TCP connection setup, the other
LSR should play passive role in IPv6 TCP connection and it aborts IPv4 TCP
connection setup, then they will have to re-try. Timing involves in such situation
but could happen.
[bmo]

Thanks

/Bin

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 12 Aug 2010 10:53:55 -0700

Hi Mark,

I have mailed the chairs at least 3 times already but have not heard
from them yet.

I realize they are probably busy with administrative work and will
probably get back some time soon.

Thanks,
Vishwas

On Wed, Aug 4, 2010 at 9:30 AM, Mark Tinka <[email-masked]> wrote:
> On Tuesday, July 27, 2010 05:39:12 am Vishwas Manral wrote:
>
>> Hi Chairs,
>>
>> We would like to request you to have a WG call to gauge
>> support and adopt the document LDP IPv6 as a working
>> Group item.
>>
> Vishwas, did you hear back from the Chairs?
>
> Mark.
>

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 13 Aug 2010 10:17:09 -0700

Hi Bin,

I agree. There are two sides to the coin.

1. Have a definitive way of doing things. However what this means is
this can cause disruption. So if the IPv6 session comes up first it is
disrupted when the IPv4 session comes up later.
2. Not allowing disruption causes indefinitness.

We can take a call the other way too if the WG so decides.

Thanks,
Vishwas

On Fri, Aug 13, 2010 at 7:50 AM, Bin Mo (bmo) <[email-masked]> wrote:
> Hi Mach,
>
> One problem of using LDP identifier to determine the active/passive role
> is backward compatibility, i.e. when you inter-op with old box, they
> will make decision based on different thing.
>
> It might be ok to use the IPv4 transport address to determine who plays
> active/passive role in setup IPv4 TCP, and similarly in setup IPv6 TCP.
>
> My problem is there isn't a determinative way for both sides to abandon
> the same connection. The proposed mechanism of abandon the later
> connection may means different connection on each side.
>
> Thanks
>
> /Bin
>
>> From: Mach Chen [mailto:[email-masked]]
>> Sent: Friday, August 13, 2010 3:54 AM
>> To: Bin Mo (bmo); Vishwas Manral
>> Subject: Re: [mpls] LDP IPv6
>>
>> Hi Bin and Vishwas,
>>
>> --------------------------------------------------
>> From: "Bin Mo (bmo)" <[email-masked]>
>> Sent: Thursday, August 12, 2010 11:43 PM
>> To: "Vishwas Manral" <[email-masked]>
>> Cc: <[email-masked]>
>> Subject: Re: [mpls] LDP IPv6
>>
>> > RFC5036 says in session setup, one LSR plays passive role and the
>> other
>> > plays
>> > active role. For example, If based on the address, one LSR should
>> play
>> > passive
>> > role in IPv4 TCP connection and it aborts IPv6 TCP connection setup,
>> the
>> > other
>> > connection setup, then they will have to re-try. Timing involves in
>> such
>> > situation
>> > but could happen.
>>
>> When implement this IPv4 and IPv6 mixed function, we found the same
>> issue.
>> So, if based on the LDP identifier to detemine the active/passive
> role,
>> there will not be such a problem. How do you think?
>>
>> Best regards,
>> Mach
>
>