Re: [mpls] LDP IPv6

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Bin,

Thanks for the comments.

> [bmo] OK. The current text doesn't make this requirement clear (at least to me).

Will add some clarifying text for the above in the next revision.

> 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.

I agree to the corner case. I am beginning to realize that if we just prefer IPv6 transport, then we can solve this problem in much simpler manner (and avoid complexity of any advanced logic). I will consider clarifying this better in the next revision.

Cheers,
Rajiv


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Bin Mo (bmo)
> Sent: Thursday, August 12, 2010 11:43 AM
> To: Vishwas Manral
> Cc: [e-mail]
> Subject: Re: [mpls] LDP IPv6
> 
> Hi Vishwas,
> 
> Thanks for your response. Please see my follow-up inline.
> 
> > Hi Bin,
> >
> > Thanks for the thoughtful points you have brought up.
> > > 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?
> >
> > 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?
> > VM> The preference can be local and is based on which transport
> > session is established first.
> [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
> 
> >
> > Do let me know if this answers your questions?
> >
> > Thanks,
> > Vishwas
> >
> > > Thanks
> > >
> > > /Bin
> > >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of
> > >> Vishwas Manral
> > >> Sent: Monday, July 26, 2010 5:39 PM
> > >> To: George Swallow (swallow); Loa Andersson
> > >> Cc: Rob Shakir; [e-mail]; [e-mail]
> > >> 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
> > >> <[e-mail]> 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 <[e-mail]>
> > 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 <[e-mail]>
> > >> >>>
> > >> >>> 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
> > >> <[e-mail]>
> > >> >>> 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: [e-mail]
> > >> >>> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Best regards,
> > >> >> Egor Zimin
> > >> >>
> > >> >
> > >> _______________________________________________
> > >> mpls mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/mpls
> > >
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls