RE: Polling for WG adoptionofdraft-chen-ccamp-ospf-interas-te-extension-02.txt

["LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>]

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:[e-mail]] 
> Envoyé : mercredi 16 mai 2007 08:48
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [e-mail]; [e-mail]
> 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" 
> <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> 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" <[e-mail]>
> > To: <[e-mail]>
> > 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.
> > > 
> > > 
> > > 
> > > 
> > >
> > 
> 
>