[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Polling for WG adoptionofdraft-chen-ccamp-ospf-interas-te-extension-02.txt
Hi Chen
>so, for point-to-point inter-AS link, as defined in this I-D, it's
>seems to be a better choice that the Link ID sub-TLV carries the TE
>router ID of the remote ASBR .
But 3630 was defined for intra AS usage.
In an inter-AS context, it would be better not to restrict this field to the remote TE Router ID only.
Kind Regards,
JL
> -----Message d'origine-----
> De : Mach Chen [mailto:mach@huawei.com]
> Envoyé : mercredi 16 mai 2007 08:48
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org
> Objet : Re: Polling for WG
> adoptionofdraft-chen-ccamp-ospf-interas-te-extension-02.txt
>
> Hi JL,
>
> first, thanks for you supports!
>
> please see inline
> ----- Original Message -----
> From: "LE ROUX Jean-Louis RD-CORE-LAN"
> <jeanlouis.leroux@orange-ftgroup.com>
> To: <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
> Sent: Wednesday, May 16, 2007 1:19 AM
> Subject: RE: Polling for WG adoption
> ofdraft-chen-ccamp-ospf-interas-te-extension-02.txt
>
>
> Hi Adrian, all
>
> This is a useful draft and I support it as WG doc.
>
> >>Mach: thanks
>
> I have one minor concern related to the link ID.
> Using the remote TE router ID is a bit restrictive and may raise
> security issues.
> Actually it would work as well with a remote interface address, for
> instance the address used to build the eBGP session, and this would
> avoid communicating yet another address.
> To summarize the link ID could be any address of the remote ASBR,
> including but not limited to the TE router ID.
>
> >>Mach:
> As defined in RFC3630:
> "The Link ID sub-TLV identifies the other end of the link. For
> point-to-point links, this is the Router ID of the neighbor. For
> multi-access links, this is the interface address of the designated
> router. The Link ID is identical to the contents of the Link ID
> field in the Router LSA for these link types. "
>
> Yes, there are several candidates could be used to summarize
> the Link ID, such as remote Router ID, remote interface
> address and remote TE router ID( sometimes maybe the same as
> Router ID), since remote interface address has already
> carried in the Remote Interface Address Sub-TLV(defined in
> RFC3630); so, for point-to-point inter-AS link, as defined in
> this I-D, it's seems to be a better choice that the Link ID
> sub-TLV carries the TE router ID of the remote ASBR .
>
> Also that would be great to have the same extension for IS-IS...
>
> >>Mach: yes, a separate I-D will be proposed soon.
>
> Regards,
>
> JL
>
> > ----- Original Message -----
> > From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Monday, April 30, 2007 11:00 PM
> > Subject: Polling for WG adoption of
> > draft-chen-ccamp-ospf-interas-te-extension-02.txt
> >
> >
> > > Hi,
> > >
> > > In Prague we discussed this draft and the general opinion
> > seemed to be that
> > > this is a useful extension, but that some clarifications
> > needed to be added
> > > to the I-D. This new revision appears to address all of the
> > concerns as
> > > below.
> > >
> > > Therefore given the interest in Prague and the relevance of
> > this I-D to our
> > > inter-domain TE charter actions, we are polling the WG for
> > adoption of this
> > > I-D as a CCAMP draft.
> > >
> > > Opinions please.
> > >
> > > Thanks
> > > Adrian and Deborah
> > >
> > > ====
> > > Overlap with L1VPN autodiscovery
> > >
> > > A question was raised as to whether there was an overlap
> > > with the L1VPN autodiscovery work used to distribute
> > > membership information (draft-ietf-l1vpn-ospf-auto-discovery)
> > >
> > > It appears that the mechanisms and purposes are different.
> > >
> > > The authors have added text to clarify that there is
> no overlap.
> > >
> > > Language change for "OSPF" becomes "OSPF-TE"
> > >
> > > Concern was raised that the I-D talked about "OSPF" but the
> > > function is "OSPF-TE".
> > >
> > > The authors have updated the I-D accordingly.
> > >
> > > Include reference to OSPFv3 as well
> > >
> > > A request was made to include OSPFv3.
> > >
> > > The authors have added text to explain that the same extensions
> > > apply to OSPF v2 and OSPF v3 TE extensions.
> > >
> > > Make it *incredibly* clear that TE distribution between ASes is
> > > not in scope.
> > >
> > > Although the I-D had plenty of this material, the authors have
> > > beefed it up further by including the list of things
> > that they are
> > > not doing from their Prague slides.
> > >
> > >
> > >
> > >
> > >
> >
>
>