Re: Polling for WG adoption ofdraft-chen-ccamp-ospf-interas-te-extension-02.txt

[Mach Chen <[e-mail]>]

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