Hi, I have some comment/questions on this topic.
First about the link type I would be concerned if we use the same link type for intra and inter domain link because I think it may lead to some confusion on legacy system. RFC3630 states that unrecognised sub TLV must be ignored. So a legacy system will actually see inter domain link as intra domain link. Generally this would probably have no consequence but the link Id of intra and inter AS link, if I understand correctly, are allocated from 2 different address spaces. So an inter AS link Id may actually match an OSPF router Id of the local domain. In this case I think it may lead to some wrong intra AS path computation from legacy system. Besides I don't really see the advantage of having a single link type. A question: is the AS sub TLV mandatory? I guess yes but I'm not sure the draft states it. Another question for my understanding about the need to advertise both directions of the TE link. I'm not sure to understand what is the goal of this. Is it to be able to advertise asymmetric TE information for each direction of the link? Thanks Fabien -----Message d'origine----- De : Mach Chen [mailto:[EMAIL PROTECTED] Envoyé : mercredi 25 juillet 2007 18:39 À : Acee Lindem; Adrian Farrel Cc : OSPF List Objet : Re: [OSPF] Inter-AS TE Hi Acess, all, > Hi Adrian, et al, > > On Jul 24, 2007, at 11:31 PM, Adrian Farrel wrote: > >> Hi Vishal, >> >>> I have a doubt regarding the opposition I heard your opposition to >>> the >>> introduction of a new Link type (Inter-AS link) field. >> >> So, the reason why a separate link type was proposed was a >> suggestion to help the other nodes (also legacy nodes) in the rest >> of the network. We wanted to allow a distinction to be made between >> inter-AS TE links and intra-AS TE links. (Note also that the intra- >> AS links may have normal IGP advertisements, but the inter-AS links >> are only advertised as TE links.) >> >> But, I think we are happy to be guided by the OSPF WG on this. > > I wouldn't base this decision solely on my questions on what is and > isn't necessary for inter-AS TE. If you look at how OSPF interacts > with iBGP, we don't require the AS numbers to permeate into OSPF Don't require does not mean don't allow, in fact, the AS number attribute of an inter-AS link is a kind of "identifier" just as other attribues and such AS number may not be from BGP. > (given that RFC 1745 is historic). However, I'd look to those > implementing this to verify that this makes sense for inter-AS TE. Yes, impementing always is the best method to check it out. The AS number attribute is optinal for per-domain method when there are no AS numbers as loose hop in the ERO. But for PCE-based path computation senario, especially for BRPC method, the AS number attribute is very useful and essential.See the following example PCE1<------->PCE2<------->PCE3 R1------R3----R5-----R7------R9-----R11 | | \ | / | | | \ | ---- | | | \ | / | -----R4----R6 --R8------R10----R12 : : - AS1 -->:<---- AS2 --->:<--- AS3 ---> In the above figure, three PCEs(PCE1 PCE2 PCE3) work together to perform inter-AS path computation, hence to setup a path from r1 to r12.The traversed domains are assumed to be selected before path computation: AS1->AS2->AS3. Firstly, the path computation request originated from r1 is relaied(by PCE1 and PCE2) to PCE3, then PCE3 begins to compute the path segments which from the entry boundary nodes that provide connection to AS2 to the destination in its responsiable domain(AS3), but PCE3 only knows that the path should be from AS2, so PCE3 needs to determine the entry boundary nodes based on its upstream AS number(AS2). And we will enhace the PCE-based senario in the next revision. Best regards, Mach > Thanks, > Acee > > > >> >> If the WG feels that we should use the same link type, that will be >> fine. But if the WG feels we should use a separate link type or >> doesn't care, we should use a different link type. >> >>> I know of CSPF implementations that do a two way check before we can >>> use a link for CSPF. In the Inter-AS case, there will not be such a >>> case. Will that not mean that even when a router is down and its LSA >>> exist, we will still use the links for SPF? >> >> Something that has been missed, I think, and was raised by John >> Drake in the meeting, is that we need to advertise both directions >> of the inter-AS TE link. That actually means that the local ASBR is >> going to do a "proxy" advertisement. >> >>> I also overheard Dave Ward comment that such information could >>> also be >>> useful in case of OAM too. >> >> Thanks, >> Adrian >> >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www1.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ > OSPF mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
